<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow-IPC: transport/asio_local_stream_socket_fwd.hpp Source File</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow-IPC<span id="projectnumber">&#160;2.0.0</span>
   </div>
   <div id="projectbrief">Flow-IPC project: Full implementation reference.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div id="nav-path" class="navpath">
  <ul>
<li class="navelem"><a class="el" href="dir_0c017496b493ff066fbbe686970307ba.html">transport</a></li>  </ul>
</div>
</div><!-- top -->
<div class="header">
  <div class="headertitle"><div class="title">asio_local_stream_socket_fwd.hpp</div></div>
</div><!--header-->
<div class="contents">
<a href="asio__local__stream__socket__fwd_8hpp.html">Go to the documentation of this file.</a><div class="fragment"><div class="line"><a id="l00001" name="l00001"></a><span class="lineno">    1</span><span class="comment">/* Flow-IPC: Core</span></div>
<div class="line"><a id="l00002" name="l00002"></a><span class="lineno">    2</span><span class="comment"> * Copyright 2023 Akamai Technologies, Inc.</span></div>
<div class="line"><a id="l00003" name="l00003"></a><span class="lineno">    3</span><span class="comment"> *</span></div>
<div class="line"><a id="l00004" name="l00004"></a><span class="lineno">    4</span><span class="comment"> * Licensed under the Apache License, Version 2.0 (the</span></div>
<div class="line"><a id="l00005" name="l00005"></a><span class="lineno">    5</span><span class="comment"> * &quot;License&quot;); you may not use this file except in</span></div>
<div class="line"><a id="l00006" name="l00006"></a><span class="lineno">    6</span><span class="comment"> * compliance with the License.  You may obtain a copy</span></div>
<div class="line"><a id="l00007" name="l00007"></a><span class="lineno">    7</span><span class="comment"> * of the License at</span></div>
<div class="line"><a id="l00008" name="l00008"></a><span class="lineno">    8</span><span class="comment"> *</span></div>
<div class="line"><a id="l00009" name="l00009"></a><span class="lineno">    9</span><span class="comment"> *   https://www.apache.org/licenses/LICENSE-2.0</span></div>
<div class="line"><a id="l00010" name="l00010"></a><span class="lineno">   10</span><span class="comment"> *</span></div>
<div class="line"><a id="l00011" name="l00011"></a><span class="lineno">   11</span><span class="comment"> * Unless required by applicable law or agreed to in</span></div>
<div class="line"><a id="l00012" name="l00012"></a><span class="lineno">   12</span><span class="comment"> * writing, software distributed under the License is</span></div>
<div class="line"><a id="l00013" name="l00013"></a><span class="lineno">   13</span><span class="comment"> * distributed on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR</span></div>
<div class="line"><a id="l00014" name="l00014"></a><span class="lineno">   14</span><span class="comment"> * CONDITIONS OF ANY KIND, either express or implied.</span></div>
<div class="line"><a id="l00015" name="l00015"></a><span class="lineno">   15</span><span class="comment"> * See the License for the specific language governing</span></div>
<div class="line"><a id="l00016" name="l00016"></a><span class="lineno">   16</span><span class="comment"> * permissions and limitations under the License. */</span></div>
<div class="line"><a id="l00017" name="l00017"></a><span class="lineno">   17</span><span class="comment"></span> </div>
<div class="line"><a id="l00018" name="l00018"></a><span class="lineno">   18</span><span class="comment">/// @file</span></div>
<div class="line"><a id="l00019" name="l00019"></a><span class="lineno">   19</span><span class="comment"></span><span class="preprocessor">#pragma once</span></div>
<div class="line"><a id="l00020" name="l00020"></a><span class="lineno">   20</span> </div>
<div class="line"><a id="l00021" name="l00021"></a><span class="lineno">   21</span><span class="preprocessor">#include &quot;<a class="code" href="transport__fwd_8hpp.html">ipc/transport/transport_fwd.hpp</a>&quot;</span></div>
<div class="line"><a id="l00022" name="l00022"></a><span class="lineno">   22</span><span class="preprocessor">#include &quot;<a class="code" href="util__fwd_8hpp.html">ipc/util/util_fwd.hpp</a>&quot;</span></div>
<div class="line"><a id="l00023" name="l00023"></a><span class="lineno">   23</span><span class="preprocessor">#include &quot;<a class="code" href="native__handle_8hpp.html">ipc/util/native_handle.hpp</a>&quot;</span></div>
<div class="line"><a id="l00024" name="l00024"></a><span class="lineno">   24</span><span class="preprocessor">#include &lt;flow/log/log.hpp&gt;</span></div>
<div class="line"><a id="l00025" name="l00025"></a><span class="lineno">   25</span><span class="preprocessor">#include &lt;boost/asio.hpp&gt;</span></div>
<div class="line"><a id="l00026" name="l00026"></a><span class="lineno">   26</span><span class="comment"></span> </div>
<div class="line"><a id="l00027" name="l00027"></a><span class="lineno">   27</span><span class="comment">/**</span></div>
<div class="line"><a id="l00028" name="l00028"></a><span class="lineno">   28</span><span class="comment"> * Additional (versus boost.asio) APIs for advanced work with local stream (Unix domain) sockets including</span></div>
<div class="line"><a id="l00029" name="l00029"></a><span class="lineno">   29</span><span class="comment"> * transmission of native handles through such streams; and peer process credentials acquisition.</span></div>
<div class="line"><a id="l00030" name="l00030"></a><span class="lineno">   30</span><span class="comment"> *</span></div>
<div class="line"><a id="l00031" name="l00031"></a><span class="lineno">   31</span><span class="comment"> * ### Rationale ###</span></div>
<div class="line"><a id="l00032" name="l00032"></a><span class="lineno">   32</span><span class="comment"> * These exist, in the first place, because internally such things as Native_socket_stream needed them for</span></div>
<div class="line"><a id="l00033" name="l00033"></a><span class="lineno">   33</span><span class="comment"> * impl purposes.  However they are of general usefulness publicly and hence are not tucked away under `detail/`.</span></div>
<div class="line"><a id="l00034" name="l00034"></a><span class="lineno">   34</span><span class="comment"> * Because, from a public API point of view, they are orthogonal to the main public APIs (like Native_socket_stream),</span></div>
<div class="line"><a id="l00035" name="l00035"></a><span class="lineno">   35</span><span class="comment"> * they are in a segregated namespace.</span></div>
<div class="line"><a id="l00036" name="l00036"></a><span class="lineno">   36</span><span class="comment"> *</span></div>
<div class="line"><a id="l00037" name="l00037"></a><span class="lineno">   37</span><span class="comment"> * That said, to conserve time without sacrificing reusability, generally speaking features were implemented only</span></div>
<div class="line"><a id="l00038" name="l00038"></a><span class="lineno">   38</span><span class="comment"> * when there was an active use case for each -- or the cost of adding them was low.  Essentially APIs are written</span></div>
<div class="line"><a id="l00039" name="l00039"></a><span class="lineno">   39</span><span class="comment"> * in such a way as to be generally usable in the same spirit as built-in boost.asio APIs -- or at least reasonably</span></div>
<div class="line"><a id="l00040" name="l00040"></a><span class="lineno">   40</span><span class="comment"> * natural to get to that point in the future.</span></div>
<div class="line"><a id="l00041" name="l00041"></a><span class="lineno">   41</span><span class="comment"> *</span></div>
<div class="line"><a id="l00042" name="l00042"></a><span class="lineno">   42</span><span class="comment"> * ### Overview ###</span></div>
<div class="line"><a id="l00043" name="l00043"></a><span class="lineno">   43</span><span class="comment"> * As of this writing `asio_local_stream_socket` has the following features w/r/t local stream (Unix domain) sockets:</span></div>
<div class="line"><a id="l00044" name="l00044"></a><span class="lineno">   44</span><span class="comment"> *   - Convenience aliases (`local_ns`, #Peer_socket, #Acceptor, #Endpoint, etc.).</span></div>
<div class="line"><a id="l00045" name="l00045"></a><span class="lineno">   45</span><span class="comment"> *   - Socket option for use with boost.asio API `Peer_socket::get_option()` that gets the opposing process&#39;s</span></div>
<div class="line"><a id="l00046" name="l00046"></a><span class="lineno">   46</span><span class="comment"> *     credentials (PID, UID, ...) (Opt_peer_process_credentials).</span></div>
<div class="line"><a id="l00047" name="l00047"></a><span class="lineno">   47</span><span class="comment"> *   - Writing of blob + native handle combos (boost.asio supports only the former)</span></div>
<div class="line"><a id="l00048" name="l00048"></a><span class="lineno">   48</span><span class="comment"> *     (nb_write_some_with_native_handle(), async_write_with_native_handle(), etc.).</span></div>
<div class="line"><a id="l00049" name="l00049"></a><span class="lineno">   49</span><span class="comment"> *   - Reading of blob + native handle combos (boost.asio supports only the former)</span></div>
<div class="line"><a id="l00050" name="l00050"></a><span class="lineno">   50</span><span class="comment"> *     (nb_read_some_with_native_handle()).</span></div>
<div class="line"><a id="l00051" name="l00051"></a><span class="lineno">   51</span><span class="comment"> *   - More advanced composed blob reading operations (async_read_with_target_func(), at least).</span></div>
<div class="line"><a id="l00052" name="l00052"></a><span class="lineno">   52</span><span class="comment"> *</span></div>
<div class="line"><a id="l00053" name="l00053"></a><span class="lineno">   53</span><span class="comment"> * @todo At least asio_local_stream_socket::async_read_with_target_func() can be extended to</span></div>
<div class="line"><a id="l00054" name="l00054"></a><span class="lineno">   54</span><span class="comment"> * other stream sockets (TCP, etc.).  In that case it should be moved to a different namespace however</span></div>
<div class="line"><a id="l00055" name="l00055"></a><span class="lineno">   55</span><span class="comment"> * (perhaps named `asio_stream_socket`; could then move the existing `asio_local_stream_socket` inside that one</span></div>
<div class="line"><a id="l00056" name="l00056"></a><span class="lineno">   56</span><span class="comment"> * and rename it `local`).</span></div>
<div class="line"><a id="l00057" name="l00057"></a><span class="lineno">   57</span><span class="comment"> *</span></div>
<div class="line"><a id="l00058" name="l00058"></a><span class="lineno">   58</span><span class="comment"> * @todo `asio_local_stream_socket` additional feature: APIs that can read and write native sockets together with</span></div>
<div class="line"><a id="l00059" name="l00059"></a><span class="lineno">   59</span><span class="comment"> * accompanying binary blobs can be extended to handle an arbitrary number of native handles (per call) as opposed to</span></div>
<div class="line"><a id="l00060" name="l00060"></a><span class="lineno">   60</span><span class="comment"> * only 0 or 1.  The main difficulty here is designing a convenient and stylish, yet performant, API.</span></div>
<div class="line"><a id="l00061" name="l00061"></a><span class="lineno">   61</span><span class="comment"> *</span></div>
<div class="line"><a id="l00062" name="l00062"></a><span class="lineno">   62</span><span class="comment"> * @todo `asio_local_stream_socket` additional feature: APIs that can read and write native handles together with</span></div>
<div class="line"><a id="l00063" name="l00063"></a><span class="lineno">   63</span><span class="comment"> * accompanying binary blobs can be extended to handle scatter/gather semantics for the aforementioned blobs,</span></div>
<div class="line"><a id="l00064" name="l00064"></a><span class="lineno">   64</span><span class="comment"> * matching standard boost.asio API functionality.</span></div>
<div class="line"><a id="l00065" name="l00065"></a><span class="lineno">   65</span><span class="comment"> *</span></div>
<div class="line"><a id="l00066" name="l00066"></a><span class="lineno">   66</span><span class="comment"> * @todo `asio_local_stream_socket` additional feature: Non-blocking APIs like nb_read_some_with_native_handle()</span></div>
<div class="line"><a id="l00067" name="l00067"></a><span class="lineno">   67</span><span class="comment"> * and nb_write_some_with_native_handle() can gain blocking counterparts, matching standard boost.asio API</span></div>
<div class="line"><a id="l00068" name="l00068"></a><span class="lineno">   68</span><span class="comment"> * functionality.</span></div>
<div class="line"><a id="l00069" name="l00069"></a><span class="lineno">   69</span><span class="comment"> *</span></div>
<div class="line"><a id="l00070" name="l00070"></a><span class="lineno">   70</span><span class="comment"> * @todo `asio_local_stream_socket` additional feature: `async_read_some_with_native_handle()` --</span></div>
<div class="line"><a id="l00071" name="l00071"></a><span class="lineno">   71</span><span class="comment"> * async version of existing nb_read_some_with_native_handle().  Or another way to put it is,</span></div>
<div class="line"><a id="l00072" name="l00072"></a><span class="lineno">   72</span><span class="comment"> * equivalent of boost.asio `Peer_socket::async_read_some()` but able to read native handle(s) with the blob.</span></div>
<div class="line"><a id="l00073" name="l00073"></a><span class="lineno">   73</span><span class="comment"> * Note: This API would potentially be usable inside the impl of existing APIs (code reuse).</span></div>
<div class="line"><a id="l00074" name="l00074"></a><span class="lineno">   74</span><span class="comment"> *</span></div>
<div class="line"><a id="l00075" name="l00075"></a><span class="lineno">   75</span><span class="comment"> * @todo `asio_local_stream_socket` additional feature: `async_read_with_native_handle()` --</span></div>
<div class="line"><a id="l00076" name="l00076"></a><span class="lineno">   76</span><span class="comment"> * async version of existing nb_read_some_with_native_handle(), plus the &quot;stubborn&quot; behavior of built-in `async_read()`</span></div>
<div class="line"><a id="l00077" name="l00077"></a><span class="lineno">   77</span><span class="comment"> * free function.  Or another way to put it is, equivalent of boost.asio `async_read&lt;Peer_socket&gt;()` but able to read</span></div>
<div class="line"><a id="l00078" name="l00078"></a><span class="lineno">   78</span><span class="comment"> * native handle(s) with the blob.</span></div>
<div class="line"><a id="l00079" name="l00079"></a><span class="lineno">   79</span><span class="comment"> * Note: This API would potentially be usable inside the impl of existing APIs (code reuse).</span></div>
<div class="line"><a id="l00080" name="l00080"></a><span class="lineno">   80</span><span class="comment"> *</span></div>
<div class="line"><a id="l00081" name="l00081"></a><span class="lineno">   81</span><span class="comment"> * @internal</span></div>
<div class="line"><a id="l00082" name="l00082"></a><span class="lineno">   82</span><span class="comment"> * ### Implementation notes ###</span></div>
<div class="line"><a id="l00083" name="l00083"></a><span class="lineno">   83</span><span class="comment"> * As one would expect the native-handle-transmission APIs use Linux `recvmsg()` and `sendmsg()` with the</span></div>
<div class="line"><a id="l00084" name="l00084"></a><span class="lineno">   84</span><span class="comment"> * `SCM_RIGHTS` ancillary-message type.  For some of the</span></div>
<div class="line"><a id="l00085" name="l00085"></a><span class="lineno">   85</span><span class="comment"> * to-dos mentioned above:</span></div>
<div class="line"><a id="l00086" name="l00086"></a><span class="lineno">   86</span><span class="comment"> *   - Both of those functions take buffers in terms of `iovec` arrays; the present impl merely provides a 1-array.</span></div>
<div class="line"><a id="l00087" name="l00087"></a><span class="lineno">   87</span><span class="comment"> *     It would be pretty easy to extend this to do scatter/gather.</span></div>
<div class="line"><a id="l00088" name="l00088"></a><span class="lineno">   88</span><span class="comment"> *   - To offer blocking versions, one can simply start a `flow::async::Single_thread_task_loop` each time</span></div>
<div class="line"><a id="l00089" name="l00089"></a><span class="lineno">   89</span><span class="comment"> *     and `post()` onto it in `S_ASYNC_AND_AWAIT_CONCURRENT_COMPLETION` mode.  Alternatively one could write more</span></div>
<div class="line"><a id="l00090" name="l00090"></a><span class="lineno">   90</span><span class="comment"> *     performant versions that would directly use the provided sockets in blocking mode; this would be much more work.</span></div>
<div class="line"><a id="l00091" name="l00091"></a><span class="lineno">   91</span><span class="comment"> */</span></div>
<div class="line"><a id="l00092" name="l00092"></a><span class="lineno">   92</span><span class="keyword">namespace </span><a class="code hl_namespace" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html">ipc::transport::asio_local_stream_socket</a></div>
<div class="line"><a id="l00093" name="l00093"></a><span class="lineno">   93</span>{</div>
<div class="line"><a id="l00094" name="l00094"></a><span class="lineno">   94</span> </div>
<div class="line"><a id="l00095" name="l00095"></a><span class="lineno">   95</span><span class="comment">// Types.</span></div>
<div class="line"><a id="l00096" name="l00096"></a><span class="lineno">   96</span> </div>
<div class="line"><a id="l00097" name="l00097"></a><span class="lineno">   97</span><span class="comment">/* (The @namespace and @brief thingies shouldn&#39;t be needed, but some Doxygen bug necessitated them.</span></div>
<div class="line"><a id="l00098" name="l00098"></a><span class="lineno">   98</span><span class="comment"> * See flow::util::bind_ns for explanation... same thing here.) */</span></div>
<div class="line"><a id="l00099" name="l00099"></a><span class="lineno">   99</span><span class="comment"></span> </div>
<div class="line"><a id="l00100" name="l00100"></a><span class="lineno">  100</span><span class="comment">/**</span></div>
<div class="line"><a id="l00101" name="l00101"></a><span class="lineno"><a class="line" href="namespaceipc_1_1transport_1_1asio__local__stream__socket_1_1local__ns.html">  101</a></span><span class="comment"> * @namespace ipc::transport::asio_local_stream_socket::local_ns</span></div>
<div class="line"><a id="l00102" name="l00102"></a><span class="lineno">  102</span><span class="comment"> * @brief Short-hand for boost.asio Unix domain socket namespace.  In particular `connect_pair()` free function lives</span></div>
<div class="line"><a id="l00103" name="l00103"></a><span class="lineno">  103</span><span class="comment"> *        here.</span></div>
<div class="line"><a id="l00104" name="l00104"></a><span class="lineno">  104</span><span class="comment"> */</span></div>
<div class="line"><a id="l00105" name="l00105"></a><span class="lineno">  105</span><span class="keyword">namespace </span>local_ns = boost::asio::local;</div>
<div class="line"><a id="l00106" name="l00106"></a><span class="lineno">  106</span><span class="comment"></span> </div>
<div class="line"><a id="l00107" name="l00107"></a><span class="lineno">  107</span><span class="comment">/// Short-hand for boost.asio Unix domain stream-socket protocol.</span></div>
<div class="line"><a id="l00108" name="l00108"></a><span class="lineno"><a class="line" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a0ad6afc0bbf995a5b84528f96315f4a2">  108</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a0ad6afc0bbf995a5b84528f96315f4a2">Protocol</a> = local_ns::stream_protocol;</div>
<div class="line"><a id="l00109" name="l00109"></a><span class="lineno">  109</span><span class="comment"></span> </div>
<div class="line"><a id="l00110" name="l00110"></a><span class="lineno">  110</span><span class="comment">/// Short-hand for boost.asio Unix domain stream-socket acceptor (listening guy) socket.</span></div>
<div class="line"><a id="l00111" name="l00111"></a><span class="lineno"><a class="line" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a154986f10d30d850de86fc3924766e66">  111</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a154986f10d30d850de86fc3924766e66">Acceptor</a> = Protocol::acceptor;</div>
<div class="line"><a id="l00112" name="l00112"></a><span class="lineno">  112</span><span class="comment"></span> </div>
<div class="line"><a id="l00113" name="l00113"></a><span class="lineno">  113</span><span class="comment">/// Short-hand for boost.asio Unix domain peer stream-socket (usually-connected-or-empty guy).</span></div>
<div class="line"><a id="l00114" name="l00114"></a><span class="lineno"><a class="line" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">  114</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">Peer_socket</a> = Protocol::socket;</div>
<div class="line"><a id="l00115" name="l00115"></a><span class="lineno">  115</span><span class="comment"></span> </div>
<div class="line"><a id="l00116" name="l00116"></a><span class="lineno">  116</span><span class="comment">/// Short-hand for boost.asio Unix domain peer stream-socket endpoint.</span></div>
<div class="line"><a id="l00117" name="l00117"></a><span class="lineno"><a class="line" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a05656e297b98f4c370841d2f9be52a5f">  117</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a05656e297b98f4c370841d2f9be52a5f">Endpoint</a> = Protocol::endpoint;</div>
<div class="line"><a id="l00118" name="l00118"></a><span class="lineno">  118</span> </div>
<div class="line"><a id="l00119" name="l00119"></a><span class="lineno">  119</span><span class="keyword">class </span><a class="code hl_class" href="classipc_1_1transport_1_1asio__local__stream__socket_1_1Opt__peer__process__credentials.html">Opt_peer_process_credentials</a>;</div>
<div class="line"><a id="l00120" name="l00120"></a><span class="lineno">  120</span> </div>
<div class="line"><a id="l00121" name="l00121"></a><span class="lineno">  121</span><span class="comment">// Free functions.</span></div>
<div class="line"><a id="l00122" name="l00122"></a><span class="lineno">  122</span><span class="comment"></span> </div>
<div class="line"><a id="l00123" name="l00123"></a><span class="lineno">  123</span><span class="comment">/**</span></div>
<div class="line"><a id="l00124" name="l00124"></a><span class="lineno">  124</span><span class="comment"> * boost.asio extension similar to</span></div>
<div class="line"><a id="l00125" name="l00125"></a><span class="lineno">  125</span><span class="comment"> * `boost::asio::async_write(Peer_socket&amp;, Blob_const, Task_err_sz)` with the added capability of</span></div>
<div class="line"><a id="l00126" name="l00126"></a><span class="lineno">  126</span><span class="comment"> * accompanying the `Blob_const` with a native handle to be transmitted to the opposing peer.</span></div>
<div class="line"><a id="l00127" name="l00127"></a><span class="lineno">  127</span><span class="comment"> *</span></div>
<div class="line"><a id="l00128" name="l00128"></a><span class="lineno">  128</span><span class="comment"> * @see Please read the &quot;Blob/handle semantics&quot; about working with native handle</span></div>
<div class="line"><a id="l00129" name="l00129"></a><span class="lineno">  129</span><span class="comment"> *      handle accompaniment, in the nb_read_some_with_native_handle() doc header.</span></div>
<div class="line"><a id="l00130" name="l00130"></a><span class="lineno">  130</span><span class="comment"> *</span></div>
<div class="line"><a id="l00131" name="l00131"></a><span class="lineno">  131</span><span class="comment"> * boost.asio&#39;s `async_write()` free function is generically capable of sending a sequence of 1+ buffers on</span></div>
<div class="line"><a id="l00132" name="l00132"></a><span class="lineno">  132</span><span class="comment"> * a connected stream socket, continuing until either the entire sequence is fully sent; or an error (not counting</span></div>
<div class="line"><a id="l00133" name="l00133"></a><span class="lineno">  133</span><span class="comment"> * would-block, which just means keep trying to make progress when possible).  The capability we add is the native</span></div>
<div class="line"><a id="l00134" name="l00134"></a><span class="lineno">  134</span><span class="comment"> * handle in `payload_hndl` is also transmitted.  Certain aspects of `async_write()` are not included in the present</span></div>
<div class="line"><a id="l00135" name="l00135"></a><span class="lineno">  135</span><span class="comment"> * function, however, though merely because they were not necessary as of this writing and hence excluded for</span></div>
<div class="line"><a id="l00136" name="l00136"></a><span class="lineno">  136</span><span class="comment"> * simplicity; these are formally described below.</span></div>
<div class="line"><a id="l00137" name="l00137"></a><span class="lineno">  137</span><span class="comment"> *</span></div>
<div class="line"><a id="l00138" name="l00138"></a><span class="lineno">  138</span><span class="comment"> * ### Formal behavior ###</span></div>
<div class="line"><a id="l00139" name="l00139"></a><span class="lineno">  139</span><span class="comment"> * This function requires that `payload_blob` be non-empty; and `payload_hndl.null() == false`.</span></div>
<div class="line"><a id="l00140" name="l00140"></a><span class="lineno">  140</span><span class="comment"> * (If you want to send a non-empty buffer but no handle, then just use boost.asio `async_write()`.</span></div>
<div class="line"><a id="l00141" name="l00141"></a><span class="lineno">  141</span><span class="comment"> * As of this writing the relevant OS shall not support sending a handle but a null buffer.)</span></div>
<div class="line"><a id="l00142" name="l00142"></a><span class="lineno">  142</span><span class="comment"> *</span></div>
<div class="line"><a id="l00143" name="l00143"></a><span class="lineno">  143</span><span class="comment"> * The function exits without blocking.  The sending occurs asynchronously.  A successful operation is defined as</span></div>
<div class="line"><a id="l00144" name="l00144"></a><span class="lineno">  144</span><span class="comment"> * sending all of the blob; and the native handle.  `on_sent_or_error()` shall be called</span></div>
<div class="line"><a id="l00145" name="l00145"></a><span class="lineno">  145</span><span class="comment"> * at most once, indicating the outcome of the operation.  (Informally: Most of the time, though asynchronous, this</span></div>
<div class="line"><a id="l00146" name="l00146"></a><span class="lineno">  146</span><span class="comment"> * should be a very fast op.  This deals with local (Unix domain as of this writing) peer connections; and the other</span></div>
<div class="line"><a id="l00147" name="l00147"></a><span class="lineno">  147</span><span class="comment"> * side likely uses ipc::transport::Native_socket_stream which takes care to read incoming messages ASAP at all times;</span></div>
<div class="line"><a id="l00148" name="l00148"></a><span class="lineno">  148</span><span class="comment"> * therefore blocking when sending should be rarer than even with remote TCP traffic.)  The following are all the</span></div>
<div class="line"><a id="l00149" name="l00149"></a><span class="lineno">  149</span><span class="comment"> * possible outcomes:</span></div>
<div class="line"><a id="l00150" name="l00150"></a><span class="lineno">  150</span><span class="comment"> *   - `on_sent_or_error(Error_code())` is executed as if `post()`ed</span></div>
<div class="line"><a id="l00151" name="l00151"></a><span class="lineno">  151</span><span class="comment"> *     on `peer_socket-&gt;get_executor()` (the `flow::util::Task_engine`,</span></div>
<div class="line"><a id="l00152" name="l00152"></a><span class="lineno">  152</span><span class="comment"> *     a/k/a boost.asio `io_context`, associated with `*peer_socket`), where `N == payload_blob.size()`.</span></div>
<div class="line"><a id="l00153" name="l00153"></a><span class="lineno">  153</span><span class="comment"> *     This indicates the entire buffer, and the handle, were sent successfully.</span></div>
<div class="line"><a id="l00154" name="l00154"></a><span class="lineno">  154</span><span class="comment"> *   - `on_sent_or_error(E)`, where `bool(E) == true`, is executed similarly.</span></div>
<div class="line"><a id="l00155" name="l00155"></a><span class="lineno">  155</span><span class="comment"> *     This indicates the send did not fully succeed, and `E` specifies why this happened.</span></div>
<div class="line"><a id="l00156" name="l00156"></a><span class="lineno">  156</span><span class="comment"> *     No indication is given how many bytes were successfully sent (if any even were).</span></div>
<div class="line"><a id="l00157" name="l00157"></a><span class="lineno">  157</span><span class="comment"> *     (Informally, there&#39;s likely not much difference between those 2 outcomes.  Either way, the connection is</span></div>
<div class="line"><a id="l00158" name="l00158"></a><span class="lineno">  158</span><span class="comment"> *     hosed.)</span></div>
<div class="line"><a id="l00159" name="l00159"></a><span class="lineno">  159</span><span class="comment"> *     - `E == boost::asio::error::operation_aborted` is possible and indicates your own code canceled pending</span></div>
<div class="line"><a id="l00160" name="l00160"></a><span class="lineno">  160</span><span class="comment"> *       async work such as by destroying `*peer_socket`.  Informally, the best way to deal</span></div>
<div class="line"><a id="l00161" name="l00161"></a><span class="lineno">  161</span><span class="comment"> *       with it is know it&#39;s normal when stuff is shutting down; and to do nothing other than maybe logging,</span></div>
<div class="line"><a id="l00162" name="l00162"></a><span class="lineno">  162</span><span class="comment"> *       but even then to not assume all relevant objects even exist; really it&#39;s best to just return right away.</span></div>
<div class="line"><a id="l00163" name="l00163"></a><span class="lineno">  163</span><span class="comment"> *       Know that upon that return the handler&#39;s captured state will be freed, as in all cases.</span></div>
<div class="line"><a id="l00164" name="l00164"></a><span class="lineno">  164</span><span class="comment"> *     - `E` will never indicate would-block.</span></div>
<div class="line"><a id="l00165" name="l00165"></a><span class="lineno">  165</span><span class="comment"> *   - `on_sent_or_error()` is canceled and not called at all, such as possibly when `stop()`ing the underlying</span></div>
<div class="line"><a id="l00166" name="l00166"></a><span class="lineno">  166</span><span class="comment"> *      `Task_engine`.  This is similar to the aforementioned `operation_aborted` situation.</span></div>
<div class="line"><a id="l00167" name="l00167"></a><span class="lineno">  167</span><span class="comment"> *      Know that upon that return the handler&#39;s captured state *will* be freed at the time of</span></div>
<div class="line"><a id="l00168" name="l00168"></a><span class="lineno">  168</span><span class="comment"> *      whatever shutdown/cancellation step.</span></div>
<div class="line"><a id="l00169" name="l00169"></a><span class="lineno">  169</span><span class="comment"> *</span></div>
<div class="line"><a id="l00170" name="l00170"></a><span class="lineno">  170</span><span class="comment"> * Items are extensively logged on `*logger_ptr`, and we follow the normal best practices to avoid verbose messages</span></div>
<div class="line"><a id="l00171" name="l00171"></a><span class="lineno">  171</span><span class="comment"> * at the severities strictly higher than `TRACE`.  In particular, any error is logged as a `WARNING`, so in particular</span></div>
<div class="line"><a id="l00172" name="l00172"></a><span class="lineno">  172</span><span class="comment"> * there&#39;s no need to for caller to specifically log about the details of a non-false `Error_code`.</span></div>
<div class="line"><a id="l00173" name="l00173"></a><span class="lineno">  173</span><span class="comment"> *</span></div>
<div class="line"><a id="l00174" name="l00174"></a><span class="lineno">  174</span><span class="comment"> * Thread safety is identical to that of `async_write_some()`.</span></div>
<div class="line"><a id="l00175" name="l00175"></a><span class="lineno">  175</span><span class="comment"> *</span></div>
<div class="line"><a id="l00176" name="l00176"></a><span class="lineno">  176</span><span class="comment"> * ### Features of `boost::asio::async_write()` not provided here ###</span></div>
<div class="line"><a id="l00177" name="l00177"></a><span class="lineno">  177</span><span class="comment"> * We have (consciously) made these concessions:</span></div>
<div class="line"><a id="l00178" name="l00178"></a><span class="lineno">  178</span><span class="comment"> *  - `payload_blob` is a single blob.  `async_write()` is templated in such a way as to accept that or a</span></div>
<div class="line"><a id="l00179" name="l00179"></a><span class="lineno">  179</span><span class="comment"> *    *sequence* of `Blob_const`s, meaning it supports scatter/gather.</span></div>
<div class="line"><a id="l00180" name="l00180"></a><span class="lineno">  180</span><span class="comment"> *  - There are also fancier advanced-async-flow-control overloads of `async_write()` with more features we haven&#39;t</span></div>
<div class="line"><a id="l00181" name="l00181"></a><span class="lineno">  181</span><span class="comment"> *    replicated.  However the simplest overload only has the preceding 3 bullet points on us.</span></div>
<div class="line"><a id="l00182" name="l00182"></a><span class="lineno">  182</span><span class="comment"> *</span></div>
<div class="line"><a id="l00183" name="l00183"></a><span class="lineno">  183</span><span class="comment"> * ### Rationale ###</span></div>
<div class="line"><a id="l00184" name="l00184"></a><span class="lineno">  184</span><span class="comment"> * This function exists because elsewhere in ipc::transport needed it internally.  It is a public API basically</span></div>
<div class="line"><a id="l00185" name="l00185"></a><span class="lineno">  185</span><span class="comment"> * opportunistically: it&#39;s generic enough to be useful in its own right potentially, but as of this writing there&#39;s</span></div>
<div class="line"><a id="l00186" name="l00186"></a><span class="lineno">  186</span><span class="comment"> * no use case.  This explains the aforementioned concessions compared to boost.asio `async_write()` free function.</span></div>
<div class="line"><a id="l00187" name="l00187"></a><span class="lineno">  187</span><span class="comment"> * All, without exception, can be implemented without controversy.  It would be busy-work and was omitted</span></div>
<div class="line"><a id="l00188" name="l00188"></a><span class="lineno">  188</span><span class="comment"> * simply because there was no need.  If we wanted to make an &quot;official-looking&quot; boost.asio extension then there would</span></div>
<div class="line"><a id="l00189" name="l00189"></a><span class="lineno">  189</span><span class="comment"> * be merit in no longer conceding those concessions.</span></div>
<div class="line"><a id="l00190" name="l00190"></a><span class="lineno">  190</span><span class="comment"> *</span></div>
<div class="line"><a id="l00191" name="l00191"></a><span class="lineno">  191</span><span class="comment"> * @internal</span></div>
<div class="line"><a id="l00192" name="l00192"></a><span class="lineno">  192</span><span class="comment"> * Update: transport::Native_socket_stream&#39;s impl has been split into itself on top and</span></div>
<div class="line"><a id="l00193" name="l00193"></a><span class="lineno">  193</span><span class="comment"> * transport::sync_io::Native_socket_stream as its core -- also available for public use.  Because the latter</span></div>
<div class="line"><a id="l00194" name="l00194"></a><span class="lineno">  194</span><span class="comment"> * is now the part doing the low-level I/O, by `sync_io` pattern&#39;s nature it can no longer be doing boost.asio</span></div>
<div class="line"><a id="l00195" name="l00195"></a><span class="lineno">  195</span><span class="comment"> * async-waits but rather outsources them to the user of that object (transport::Native_socket_stream being</span></div>
<div class="line"><a id="l00196" name="l00196"></a><span class="lineno">  196</span><span class="comment"> * a prime example).  So that means the present function is no longer used by Flow-IPC internally as of this</span></div>
<div class="line"><a id="l00197" name="l00197"></a><span class="lineno">  197</span><span class="comment"> * writing.  Still it remains a perfectly decent API; so leaving it available.</span></div>
<div class="line"><a id="l00198" name="l00198"></a><span class="lineno">  198</span><span class="comment"> *</span></div>
<div class="line"><a id="l00199" name="l00199"></a><span class="lineno">  199</span><span class="comment"> * There are to-dos elsewhere to perhaps generalize this guy and his bro(s) to support both boost.asio</span></div>
<div class="line"><a id="l00200" name="l00200"></a><span class="lineno">  200</span><span class="comment"> * and `sync_io`.  It would be some ungodly API, but it could have a boost.asio-target wrapper unchanged from</span></div>
<div class="line"><a id="l00201" name="l00201"></a><span class="lineno">  201</span><span class="comment"> * the current signature.</span></div>
<div class="line"><a id="l00202" name="l00202"></a><span class="lineno">  202</span><span class="comment"> *</span></div>
<div class="line"><a id="l00203" name="l00203"></a><span class="lineno">  203</span><span class="comment"> * These 3 paragraphs apply, to one extent or another, to async_write_with_native_handle(),</span></div>
<div class="line"><a id="l00204" name="l00204"></a><span class="lineno">  204</span><span class="comment"> * async_read_with_target_func(), and async_read_interruptible().</span></div>
<div class="line"><a id="l00205" name="l00205"></a><span class="lineno">  205</span><span class="comment"> * @endinternal</span></div>
<div class="line"><a id="l00206" name="l00206"></a><span class="lineno">  206</span><span class="comment"> *</span></div>
<div class="line"><a id="l00207" name="l00207"></a><span class="lineno">  207</span><span class="comment"> * @tparam Task_err</span></div>
<div class="line"><a id="l00208" name="l00208"></a><span class="lineno">  208</span><span class="comment"> *         boost.asio handler with same signature as `flow::async::Task_asio_err`.</span></div>
<div class="line"><a id="l00209" name="l00209"></a><span class="lineno">  209</span><span class="comment"> *         It can be bound to an executor (commonly, a `strand`); this will be respected.</span></div>
<div class="line"><a id="l00210" name="l00210"></a><span class="lineno">  210</span><span class="comment"> * @param logger_ptr</span></div>
<div class="line"><a id="l00211" name="l00211"></a><span class="lineno">  211</span><span class="comment"> *        Logger to use for subsequently logging.</span></div>
<div class="line"><a id="l00212" name="l00212"></a><span class="lineno">  212</span><span class="comment"> * @param peer_socket</span></div>
<div class="line"><a id="l00213" name="l00213"></a><span class="lineno">  213</span><span class="comment"> *        Pointer to stream socket.  If it is not connected, or otherwise unsuitable, behavior is identical to</span></div>
<div class="line"><a id="l00214" name="l00214"></a><span class="lineno">  214</span><span class="comment"> *        attempting `async_write()` on such a socket.  If null behavior is undefined (assertion may trip).</span></div>
<div class="line"><a id="l00215" name="l00215"></a><span class="lineno">  215</span><span class="comment"> * @param payload_hndl</span></div>
<div class="line"><a id="l00216" name="l00216"></a><span class="lineno">  216</span><span class="comment"> *        The native handle to transmit.  If `payload_hndl.is_null()` behavior is undefined (possible</span></div>
<div class="line"><a id="l00217" name="l00217"></a><span class="lineno">  217</span><span class="comment"> *        assertion trip).</span></div>
<div class="line"><a id="l00218" name="l00218"></a><span class="lineno">  218</span><span class="comment"> * @param payload_blob</span></div>
<div class="line"><a id="l00219" name="l00219"></a><span class="lineno">  219</span><span class="comment"> *        The buffer to transmit.  Reiterating the above outcome semantics: Either there is no error, and then</span></div>
<div class="line"><a id="l00220" name="l00220"></a><span class="lineno">  220</span><span class="comment"> *        the `N` passed to the handler callback will equal `payload_blob.size()`; or there is a truthy `Error_code`,</span></div>
<div class="line"><a id="l00221" name="l00221"></a><span class="lineno">  221</span><span class="comment"> *        and `N` will be strictly less than `payload_blob.size()`.</span></div>
<div class="line"><a id="l00222" name="l00222"></a><span class="lineno">  222</span><span class="comment"> * @param on_sent_or_error</span></div>
<div class="line"><a id="l00223" name="l00223"></a><span class="lineno">  223</span><span class="comment"> *        Handler to execute at most once on completion of the async op.  It is executed as if via</span></div>
<div class="line"><a id="l00224" name="l00224"></a><span class="lineno">  224</span><span class="comment"> *        `post(peer_socket-&gt;get_executor())`, fully respecting any executor</span></div>
<div class="line"><a id="l00225" name="l00225"></a><span class="lineno">  225</span><span class="comment"> *        bound to it (via `bind_executor()`, such as a strand).</span></div>
<div class="line"><a id="l00226" name="l00226"></a><span class="lineno">  226</span><span class="comment"> *        It shall be passed `Error_code`.  The semantics of these values are shown above.</span></div>
<div class="line"><a id="l00227" name="l00227"></a><span class="lineno">  227</span><span class="comment"> *        Informally: falsy `Error_code` indicates total success of sending both items; truthy `Error_code`</span></div>
<div class="line"><a id="l00228" name="l00228"></a><span class="lineno">  228</span><span class="comment"> *        indicates a connection-fatal error prevented us from some or both being fully sent; one should disregard</span></div>
<div class="line"><a id="l00229" name="l00229"></a><span class="lineno">  229</span><span class="comment"> *        `operation_aborted` and do nothing; else one should consider the connection as hosed (possibly gracefully) and</span></div>
<div class="line"><a id="l00230" name="l00230"></a><span class="lineno">  230</span><span class="comment"> *        take steps having discovered this.</span></div>
<div class="line"><a id="l00231" name="l00231"></a><span class="lineno">  231</span><span class="comment"> */</span></div>
<div class="line"><a id="l00232" name="l00232"></a><span class="lineno">  232</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Task_err&gt;</div>
<div class="line"><a id="l00233" name="l00233"></a><span class="lineno">  233</span><span class="keywordtype">void</span> <a class="code hl_function" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a68071e53f4a048084f8ad26ff3ac6711">async_write_with_native_handle</a>(flow::log::Logger* logger_ptr,</div>
<div class="line"><a id="l00234" name="l00234"></a><span class="lineno">  234</span>                                    <a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">Peer_socket</a>* peer_socket,</div>
<div class="line"><a id="l00235" name="l00235"></a><span class="lineno">  235</span>                                    <a class="code hl_struct" href="structipc_1_1util_1_1Native__handle.html">Native_handle</a> payload_hndl, <span class="keyword">const</span> <a class="code hl_typedef" href="namespaceipc_1_1util.html#ae0be7edba7e30ffa3f8b742af621f2ab">util::Blob_const</a>&amp; payload_blob,</div>
<div class="line"><a id="l00236" name="l00236"></a><span class="lineno">  236</span>                                    Task_err&amp;&amp; on_sent_or_error);</div>
<div class="line"><a id="l00237" name="l00237"></a><span class="lineno">  237</span><span class="comment"></span> </div>
<div class="line"><a id="l00238" name="l00238"></a><span class="lineno">  238</span><span class="comment">/**</span></div>
<div class="line"><a id="l00239" name="l00239"></a><span class="lineno">  239</span><span class="comment"> * boost.asio extension similar to</span></div>
<div class="line"><a id="l00240" name="l00240"></a><span class="lineno">  240</span><span class="comment"> * `peer_socket-&gt;non_blocking(true); auto n = peer_socket-&gt;write_some(payload_blob)` with the added</span></div>
<div class="line"><a id="l00241" name="l00241"></a><span class="lineno">  241</span><span class="comment"> * capability of accompanying the `Blob_const payload_blob` with a native handle to be transmitted to the</span></div>
<div class="line"><a id="l00242" name="l00242"></a><span class="lineno">  242</span><span class="comment"> * opposing peer.</span></div>
<div class="line"><a id="l00243" name="l00243"></a><span class="lineno">  243</span><span class="comment"> *</span></div>
<div class="line"><a id="l00244" name="l00244"></a><span class="lineno">  244</span><span class="comment"> * In other words it attempts to immediately send `payload_hndl` and at least 1 byte of `payload_blob`;</span></div>
<div class="line"><a id="l00245" name="l00245"></a><span class="lineno">  245</span><span class="comment"> * returns would-block error code if this would require blocking; or another error if the connection has become hosed.</span></div>
<div class="line"><a id="l00246" name="l00246"></a><span class="lineno">  246</span><span class="comment"> * Performing `peer_socket-&gt;write_some()` given `peer_socket-&gt;non_blocking() == true` has the same semantics except</span></div>
<div class="line"><a id="l00247" name="l00247"></a><span class="lineno">  247</span><span class="comment"> * it cannot and will not transmit any native handle.</span></div>
<div class="line"><a id="l00248" name="l00248"></a><span class="lineno">  248</span><span class="comment"> *</span></div>
<div class="line"><a id="l00249" name="l00249"></a><span class="lineno">  249</span><span class="comment"> * @see Please read the &quot;Blob/handle semantics&quot; about working with native</span></div>
<div class="line"><a id="l00250" name="l00250"></a><span class="lineno">  250</span><span class="comment"> *      handle accompaniment, in the nb_read_some_with_native_handle() doc header.</span></div>
<div class="line"><a id="l00251" name="l00251"></a><span class="lineno">  251</span><span class="comment"> *</span></div>
<div class="line"><a id="l00252" name="l00252"></a><span class="lineno">  252</span><span class="comment"> * Certain aspects of `Peer_socket::write_some()` are not included in the present function, however, though merely</span></div>
<div class="line"><a id="l00253" name="l00253"></a><span class="lineno">  253</span><span class="comment"> * because they were not necessary as of this writing and hence excluded for simplicity; these are formally described</span></div>
<div class="line"><a id="l00254" name="l00254"></a><span class="lineno">  254</span><span class="comment"> * below.</span></div>
<div class="line"><a id="l00255" name="l00255"></a><span class="lineno">  255</span><span class="comment"> *</span></div>
<div class="line"><a id="l00256" name="l00256"></a><span class="lineno">  256</span><span class="comment"> * ### Formal behavior ###</span></div>
<div class="line"><a id="l00257" name="l00257"></a><span class="lineno">  257</span><span class="comment"> * This function requires that `payload_blob` be non-empty; and `payload_hndl.null() == false`.</span></div>
<div class="line"><a id="l00258" name="l00258"></a><span class="lineno">  258</span><span class="comment"> * (If you want to send a non-empty buffer but no handle, then just use boost.asio `Peer_socket::write_some()`.</span></div>
<div class="line"><a id="l00259" name="l00259"></a><span class="lineno">  259</span><span class="comment"> * As of this writing the relevant OS shall not support receive a handle but a null buffer.)</span></div>
<div class="line"><a id="l00260" name="l00260"></a><span class="lineno">  260</span><span class="comment"> *</span></div>
<div class="line"><a id="l00261" name="l00261"></a><span class="lineno">  261</span><span class="comment"> * The function exits without blocking.  The sending occurs synchronously, if possible, or does not occur otherwise.</span></div>
<div class="line"><a id="l00262" name="l00262"></a><span class="lineno">  262</span><span class="comment"> * A successful operation is defined as sending 1+ bytes of the blob; and the native handle.  It is not possible</span></div>
<div class="line"><a id="l00263" name="l00263"></a><span class="lineno">  263</span><span class="comment"> * that the native handle is transmitted but 0 bytes of the blob are.  See `flow::Error_code` docs for error reporting</span></div>
<div class="line"><a id="l00264" name="l00264"></a><span class="lineno">  264</span><span class="comment"> * semantics (if `err_code` is non-null, `*err_code` is set to code or success; else exception with that code is</span></div>
<div class="line"><a id="l00265" name="l00265"></a><span class="lineno">  265</span><span class="comment"> * thrown in the former [non-success] case).  (Informally: Most of the time, assuming no error condition on the</span></div>
<div class="line"><a id="l00266" name="l00266"></a><span class="lineno">  266</span><span class="comment"> * connection, the function will return success.  This deals with local (Unix domain as of this writing) peer</span></div>
<div class="line"><a id="l00267" name="l00267"></a><span class="lineno">  267</span><span class="comment"> * connections; and the other side likely uses ipc::transport::Native_socket_stream which takes care to read incoming</span></div>
<div class="line"><a id="l00268" name="l00268"></a><span class="lineno">  268</span><span class="comment"> * messages ASAP at all times; therefore would-block when sending should be rarer than even with remote TCP traffic.)</span></div>
<div class="line"><a id="l00269" name="l00269"></a><span class="lineno">  269</span><span class="comment"> *</span></div>
<div class="line"><a id="l00270" name="l00270"></a><span class="lineno">  270</span><span class="comment"> * The following are all the possible outcomes:</span></div>
<div class="line"><a id="l00271" name="l00271"></a><span class="lineno">  271</span><span class="comment"> *   - `N &gt; 0` is returned; and `*err_code == Error_code()` if non-null.</span></div>
<div class="line"><a id="l00272" name="l00272"></a><span class="lineno">  272</span><span class="comment"> *     This indicates 1 or more (`N`) bytes of the buffer, and the handle, were sent successfully.</span></div>
<div class="line"><a id="l00273" name="l00273"></a><span class="lineno">  273</span><span class="comment"> *     If `N != payload_blob.size()`, then the remaining bytes cannot currently be sent without blocking and should</span></div>
<div class="line"><a id="l00274" name="l00274"></a><span class="lineno">  274</span><span class="comment"> *     be tried later.  (Informally: Consider async_write_with_native_handle() in that case.)</span></div>
<div class="line"><a id="l00275" name="l00275"></a><span class="lineno">  275</span><span class="comment"> *   - If non-null `err_code`, then `N == 0` is returned; and `*err_code == E` is set to the triggering problem.</span></div>
<div class="line"><a id="l00276" name="l00276"></a><span class="lineno">  276</span><span class="comment"> *     If null, then `flow::error::Runtime_error` is thrown containing `Error_code E`.</span></div>
<div class="line"><a id="l00277" name="l00277"></a><span class="lineno">  277</span><span class="comment"> *     - `E == boost::asio::error::would_block` specifically indicates the non-fatal condition wherein `*peer_socket`</span></div>
<div class="line"><a id="l00278" name="l00278"></a><span class="lineno">  278</span><span class="comment"> *       cannot currently send, until it reaches writable state again.</span></div>
<div class="line"><a id="l00279" name="l00279"></a><span class="lineno">  279</span><span class="comment"> *     - Other `E` values indicate the connection is (potentially gracefully) permanently incapable of transmission.</span></div>
<div class="line"><a id="l00280" name="l00280"></a><span class="lineno">  280</span><span class="comment"> *     - `E == operation_aborted` is not possible.</span></div>
<div class="line"><a id="l00281" name="l00281"></a><span class="lineno">  281</span><span class="comment"> *</span></div>
<div class="line"><a id="l00282" name="l00282"></a><span class="lineno">  282</span><span class="comment"> * Items are extensively logged on `*logger_ptr`, and we follow the normal best practices to avoid verbose messages</span></div>
<div class="line"><a id="l00283" name="l00283"></a><span class="lineno">  283</span><span class="comment"> * at the severities strictly higher than `TRACE`.  In particular, any error is logged as a `WARNING`, so in particular</span></div>
<div class="line"><a id="l00284" name="l00284"></a><span class="lineno">  284</span><span class="comment"> * there&#39;s no need to for caller to specifically log about the details of a non-false `E`.</span></div>
<div class="line"><a id="l00285" name="l00285"></a><span class="lineno">  285</span><span class="comment"> *</span></div>
<div class="line"><a id="l00286" name="l00286"></a><span class="lineno">  286</span><span class="comment"> * ### Features of `Peer_socket::write_some()` not provided here ###</span></div>
<div class="line"><a id="l00287" name="l00287"></a><span class="lineno">  287</span><span class="comment"> * We have (consciously) made these concessions:</span></div>
<div class="line"><a id="l00288" name="l00288"></a><span class="lineno">  288</span><span class="comment"> *  - `payload_blob` is a single blob.  `write_some()` is templated in such a way as to accept that or a</span></div>
<div class="line"><a id="l00289" name="l00289"></a><span class="lineno">  289</span><span class="comment"> *    *sequence* of `Blob_const`s, meaning it supports scatter/gather.</span></div>
<div class="line"><a id="l00290" name="l00290"></a><span class="lineno">  290</span><span class="comment"> *  - This function never blocks, regardless of `peer_socket-&gt;non_blocking()`.  `write_some()` -- if unable to</span></div>
<div class="line"><a id="l00291" name="l00291"></a><span class="lineno">  291</span><span class="comment"> *    immediately send 1+ bytes -- will block until it can, if `peer_socket-&gt;non_blocking() == false` mode had been</span></div>
<div class="line"><a id="l00292" name="l00292"></a><span class="lineno">  292</span><span class="comment"> *    set.  (That&#39;s why we named it `nb_...()`.)</span></div>
<div class="line"><a id="l00293" name="l00293"></a><span class="lineno">  293</span><span class="comment"> *</span></div>
<div class="line"><a id="l00294" name="l00294"></a><span class="lineno">  294</span><span class="comment"> * The following is not a concession, and these words may be redundant, but: `Peer_socket::write_some()` has</span></div>
<div class="line"><a id="l00295" name="l00295"></a><span class="lineno">  295</span><span class="comment"> * 2 overloads; one that throws exception on error; and one that takes an `Error_code&amp;`; whereas we combine the two</span></div>
<div class="line"><a id="l00296" name="l00296"></a><span class="lineno">  296</span><span class="comment"> * via the `Error_code*` null-vs-not dichotomy.  (It&#39;s redundant, because it&#39;s just following the Flow pattern.)</span></div>
<div class="line"><a id="l00297" name="l00297"></a><span class="lineno">  297</span><span class="comment"> *</span></div>
<div class="line"><a id="l00298" name="l00298"></a><span class="lineno">  298</span><span class="comment"> * Lastly, `Peer_socket::send()` is identical to `Peer_socket::write_some()` but adds an overload wherein one can</span></div>
<div class="line"><a id="l00299" name="l00299"></a><span class="lineno">  299</span><span class="comment"> * pass in a (largely unportable, I (ygoldfel) think) `message_flags` bit mask.  We do not provide this feature: again</span></div>
<div class="line"><a id="l00300" name="l00300"></a><span class="lineno">  300</span><span class="comment"> * because it is not needed, but also because depending on the flag it may lead to unexpected corner cases, and we&#39;d</span></div>
<div class="line"><a id="l00301" name="l00301"></a><span class="lineno">  301</span><span class="comment"> * rather not deal with those unless needed in practice.</span></div>
<div class="line"><a id="l00302" name="l00302"></a><span class="lineno">  302</span><span class="comment"> *</span></div>
<div class="line"><a id="l00303" name="l00303"></a><span class="lineno">  303</span><span class="comment"> * ### Rationale ###</span></div>
<div class="line"><a id="l00304" name="l00304"></a><span class="lineno">  304</span><span class="comment"> * This function exists because... [text omitted -- same reasoning as similar rationale for</span></div>
<div class="line"><a id="l00305" name="l00305"></a><span class="lineno">  305</span><span class="comment"> * async_write_with_native_handle()].</span></div>
<div class="line"><a id="l00306" name="l00306"></a><span class="lineno">  306</span><span class="comment"> *</span></div>
<div class="line"><a id="l00307" name="l00307"></a><span class="lineno">  307</span><span class="comment"> * @param logger_ptr</span></div>
<div class="line"><a id="l00308" name="l00308"></a><span class="lineno">  308</span><span class="comment"> *        Logger to use for subsequently logging.</span></div>
<div class="line"><a id="l00309" name="l00309"></a><span class="lineno">  309</span><span class="comment"> * @param peer_socket</span></div>
<div class="line"><a id="l00310" name="l00310"></a><span class="lineno">  310</span><span class="comment"> *        Pointer to stream socket.  If it is not connected, or otherwise unsuitable, behavior is identical to</span></div>
<div class="line"><a id="l00311" name="l00311"></a><span class="lineno">  311</span><span class="comment"> *        attempting `write_some()` on such a socket.  If null behavior is undefined (assertion may trip).</span></div>
<div class="line"><a id="l00312" name="l00312"></a><span class="lineno">  312</span><span class="comment"> * @param payload_hndl</span></div>
<div class="line"><a id="l00313" name="l00313"></a><span class="lineno">  313</span><span class="comment"> *        The native handle to transmit.  If `payload_hndl.is_null()` behavior is undefined (possible</span></div>
<div class="line"><a id="l00314" name="l00314"></a><span class="lineno">  314</span><span class="comment"> *        assertion trip).  Reiterating the above outcome semantics: if the return value `N` indicates even 1 byte</span></div>
<div class="line"><a id="l00315" name="l00315"></a><span class="lineno">  315</span><span class="comment"> *        was sent, then this was successfully sent also.</span></div>
<div class="line"><a id="l00316" name="l00316"></a><span class="lineno">  316</span><span class="comment"> * @param payload_blob</span></div>
<div class="line"><a id="l00317" name="l00317"></a><span class="lineno">  317</span><span class="comment"> *        The buffer to transmit.  Reiterating the above outcome semantics: Either there is no error, and then the</span></div>
<div class="line"><a id="l00318" name="l00318"></a><span class="lineno">  318</span><span class="comment"> *        `N` returned will be 1+; or a truthy `Error_code` is returned either via the out-arg or via thrown</span></div>
<div class="line"><a id="l00319" name="l00319"></a><span class="lineno">  319</span><span class="comment"> *        `Runtime_error`, and in the former case 0 is returned.</span></div>
<div class="line"><a id="l00320" name="l00320"></a><span class="lineno">  320</span><span class="comment"> * @param err_code</span></div>
<div class="line"><a id="l00321" name="l00321"></a><span class="lineno">  321</span><span class="comment"> *        See `flow::Error_code` docs for error reporting semantics.  #Error_code generated:</span></div>
<div class="line"><a id="l00322" name="l00322"></a><span class="lineno">  322</span><span class="comment"> *        `boost::asio::error::would_block` (socket not writable, likely because other side isn&#39;t reading ASAP),</span></div>
<div class="line"><a id="l00323" name="l00323"></a><span class="lineno">  323</span><span class="comment"> *        other system codes (see notes above in the outcome discussion).</span></div>
<div class="line"><a id="l00324" name="l00324"></a><span class="lineno">  324</span><span class="comment"> * @return 0 if non-null `err_code` and truthy resulting `*err_code`, and hence no bytes or the handle was sent; 1+</span></div>
<div class="line"><a id="l00325" name="l00325"></a><span class="lineno">  325</span><span class="comment"> *         if that number of bytes were sent plus the native handle (and hence falsy `*err_code` if non-null).</span></div>
<div class="line"><a id="l00326" name="l00326"></a><span class="lineno">  326</span><span class="comment"> */</span></div>
<div class="line"><a id="l00327" name="l00327"></a><span class="lineno">  327</span><span class="keywordtype">size_t</span> <a class="code hl_function" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1022dfd42e9a0d6eab8384b0352decb0">nb_write_some_with_native_handle</a>(flow::log::Logger* logger_ptr,</div>
<div class="line"><a id="l00328" name="l00328"></a><span class="lineno">  328</span>                                        <a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">Peer_socket</a>* peer_socket,</div>
<div class="line"><a id="l00329" name="l00329"></a><span class="lineno">  329</span>                                        <a class="code hl_struct" href="structipc_1_1util_1_1Native__handle.html">Native_handle</a> payload_hndl, <span class="keyword">const</span> <a class="code hl_typedef" href="namespaceipc_1_1util.html#ae0be7edba7e30ffa3f8b742af621f2ab">util::Blob_const</a>&amp; payload_blob,</div>
<div class="line"><a id="l00330" name="l00330"></a><span class="lineno">  330</span>                                        <a class="code hl_typedef" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">Error_code</a>* err_code);</div>
<div class="line"><a id="l00331" name="l00331"></a><span class="lineno">  331</span><span class="comment"></span> </div>
<div class="line"><a id="l00332" name="l00332"></a><span class="lineno">  332</span><span class="comment">/**</span></div>
<div class="line"><a id="l00333" name="l00333"></a><span class="lineno">  333</span><span class="comment"> * boost.asio extension similar to</span></div>
<div class="line"><a id="l00334" name="l00334"></a><span class="lineno">  334</span><span class="comment"> * `peer_socket-&gt;non_blocking(true); auto n = peer_socket-&gt;read_some(target_payload_blob)` with the added</span></div>
<div class="line"><a id="l00335" name="l00335"></a><span class="lineno">  335</span><span class="comment"> * capability of reading (from opposing peer) not only `Blob_mutable target_payload_blob` but an optionally accompanying</span></div>
<div class="line"><a id="l00336" name="l00336"></a><span class="lineno">  336</span><span class="comment"> * native handle.</span></div>
<div class="line"><a id="l00337" name="l00337"></a><span class="lineno">  337</span><span class="comment"> *</span></div>
<div class="line"><a id="l00338" name="l00338"></a><span class="lineno">  338</span><span class="comment"> * In other words it attempts to immediately read at least 1 byte into `*target_payload_blob`</span></div>
<div class="line"><a id="l00339" name="l00339"></a><span class="lineno">  339</span><span class="comment"> * and, if also present, the native handle into `*target_payload_hndl`; returns would-block error code if this</span></div>
<div class="line"><a id="l00340" name="l00340"></a><span class="lineno">  340</span><span class="comment"> * would require blocking; or another error if the connection has become hosed.  Performing `peer_socket-&gt;read_some()`</span></div>
<div class="line"><a id="l00341" name="l00341"></a><span class="lineno">  341</span><span class="comment"> * given `peer_socket-&gt;non_blocking() == true` has the same semantics except it cannot and will not read any native</span></div>
<div class="line"><a id="l00342" name="l00342"></a><span class="lineno">  342</span><span class="comment"> * handle.  (It would probably just &quot;eat it&quot;/ignore it; though we have not tested that at this time.)</span></div>
<div class="line"><a id="l00343" name="l00343"></a><span class="lineno">  343</span><span class="comment"> *</span></div>
<div class="line"><a id="l00344" name="l00344"></a><span class="lineno">  344</span><span class="comment"> * Certain aspects of `Peer_socket::read_some()` are not included in the present function, however, though merely</span></div>
<div class="line"><a id="l00345" name="l00345"></a><span class="lineno">  345</span><span class="comment"> * because they were not necessary as of this writing and hence excluded for simplicity; these are formally described</span></div>
<div class="line"><a id="l00346" name="l00346"></a><span class="lineno">  346</span><span class="comment"> * below.</span></div>
<div class="line"><a id="l00347" name="l00347"></a><span class="lineno">  347</span><span class="comment"> *</span></div>
<div class="line"><a id="l00348" name="l00348"></a><span class="lineno">  348</span><span class="comment"> * ### Formal behavior ###</span></div>
<div class="line"><a id="l00349" name="l00349"></a><span class="lineno">  349</span><span class="comment"> * This function requires that `target_payload_blob` be non-empty.  It shall at entry set `*target_payload_hndl`</span></div>
<div class="line"><a id="l00350" name="l00350"></a><span class="lineno">  350</span><span class="comment"> * so that `target_payload_hndl-&gt;null() == true`.  `target_payload_hndl` (the pointer) must not be null.</span></div>
<div class="line"><a id="l00351" name="l00351"></a><span class="lineno">  351</span><span class="comment"> * (If you want to receive into non-empty buffer but expect no handle, then just use boost.asio</span></div>
<div class="line"><a id="l00352" name="l00352"></a><span class="lineno">  352</span><span class="comment"> * `Peer_socket::read_some()`.  If you want to receive a non-empty buffer but no handle, then just use</span></div>
<div class="line"><a id="l00353" name="l00353"></a><span class="lineno">  353</span><span class="comment"> * boost.asio `async_write()`.  As of this writing the relevant OS shall not support receiving a handle but a</span></div>
<div class="line"><a id="l00354" name="l00354"></a><span class="lineno">  354</span><span class="comment"> * null buffer.)</span></div>
<div class="line"><a id="l00355" name="l00355"></a><span class="lineno">  355</span><span class="comment"> *</span></div>
<div class="line"><a id="l00356" name="l00356"></a><span class="lineno">  356</span><span class="comment"> * The function exits without blocking.  The receiving occurs synchronously, if possible, or does not occur otherwise.</span></div>
<div class="line"><a id="l00357" name="l00357"></a><span class="lineno">  357</span><span class="comment"> * A successful operation is defined as receiving 1+ bytes into the blob; and the native handle if it was present.</span></div>
<div class="line"><a id="l00358" name="l00358"></a><span class="lineno">  358</span><span class="comment"> * It is not possible that a native handle is received but 0 bytes of the blob are.  See `flow::Error_code` docs for</span></div>
<div class="line"><a id="l00359" name="l00359"></a><span class="lineno">  359</span><span class="comment"> * error reporting semantics (if `err_code` is non-null, `*err_code` is set to code or success; else exception with</span></div>
<div class="line"><a id="l00360" name="l00360"></a><span class="lineno">  360</span><span class="comment"> * that code is thrown in the former [non-success] case).</span></div>
<div class="line"><a id="l00361" name="l00361"></a><span class="lineno">  361</span><span class="comment"> *</span></div>
<div class="line"><a id="l00362" name="l00362"></a><span class="lineno">  362</span><span class="comment"> * The following are all the possible outcomes:</span></div>
<div class="line"><a id="l00363" name="l00363"></a><span class="lineno">  363</span><span class="comment"> *   - `N &gt; 0` is returned; and `*err_code == Error_code()` if non-null.</span></div>
<div class="line"><a id="l00364" name="l00364"></a><span class="lineno">  364</span><span class="comment"> *     This indicates 1 or more (`N`) bytes were placed at the start of the buffer, and *if* exactly 1 native handle</span></div>
<div class="line"><a id="l00365" name="l00365"></a><span class="lineno">  365</span><span class="comment"> *     handle was transmitted along with some subset of those `N` bytes, *then* it was successfully received into</span></div>
<div class="line"><a id="l00366" name="l00366"></a><span class="lineno">  366</span><span class="comment"> *     `*target_payload_hndl`; or else the fact there were exactly 0 such handles was successfully determined and</span></div>
<div class="line"><a id="l00367" name="l00367"></a><span class="lineno">  367</span><span class="comment"> *     reflected via `target_payload_hndl-&gt;null() == true`.</span></div>
<div class="line"><a id="l00368" name="l00368"></a><span class="lineno">  368</span><span class="comment"> *     If `N != target_payload_blob.size()`, then no further bytes can currently be read without blocking and should</span></div>
<div class="line"><a id="l00369" name="l00369"></a><span class="lineno">  369</span><span class="comment"> *     be tried later if desired.  (Informally: In that case consider `Peer_socket::async_wait()` followed by retrying</span></div>
<div class="line"><a id="l00370" name="l00370"></a><span class="lineno">  370</span><span class="comment"> *     the present function, in that case.)</span></div>
<div class="line"><a id="l00371" name="l00371"></a><span class="lineno">  371</span><span class="comment"> *   - If non-null `err_code`, then `N == 0` is returned; and `*err_code == E` is set to the triggering problem.</span></div>
<div class="line"><a id="l00372" name="l00372"></a><span class="lineno">  372</span><span class="comment"> *     If null, then `flow::error::Runtime_error` is thrown containing `Error_code E`.</span></div>
<div class="line"><a id="l00373" name="l00373"></a><span class="lineno">  373</span><span class="comment"> *     - `E == boost::asio::error::would_block` specifically indicates the non-fatal condition wherein `*peer_socket`</span></div>
<div class="line"><a id="l00374" name="l00374"></a><span class="lineno">  374</span><span class="comment"> *       cannot currently receive, until it reaches readable state again (i.e., bytes and possibly handle arrive from</span></div>
<div class="line"><a id="l00375" name="l00375"></a><span class="lineno">  375</span><span class="comment"> *       peer).</span></div>
<div class="line"><a id="l00376" name="l00376"></a><span class="lineno">  376</span><span class="comment"> *     - Other `E` values indicate the connection is (potentially gracefully) permanently incapable of transmission.</span></div>
<div class="line"><a id="l00377" name="l00377"></a><span class="lineno">  377</span><span class="comment"> *       - In particular `E == boost::asio::error::eof` indicates the connection was gracefully closed by peer.</span></div>
<div class="line"><a id="l00378" name="l00378"></a><span class="lineno">  378</span><span class="comment"> *         (Informally, this is usually not to be treated differently from other fatal errors like</span></div>
<div class="line"><a id="l00379" name="l00379"></a><span class="lineno">  379</span><span class="comment"> *         `boost::asio::error::connection_reset`.)</span></div>
<div class="line"><a id="l00380" name="l00380"></a><span class="lineno">  380</span><span class="comment"> *       - It may be tempting to distinguish between &quot;true&quot; system errors (probably from `boost::asio::error::`)</span></div>
<div class="line"><a id="l00381" name="l00381"></a><span class="lineno">  381</span><span class="comment"> *         and &quot;protocol&quot; errors from `ipc::transport::error::Code` (as of this writing</span></div>
<div class="line"><a id="l00382" name="l00382"></a><span class="lineno">  382</span><span class="comment"> *         `S_LOW_LVL_UNEXPECTED_STREAM_PAYLOAD_BEYOND_HNDL`): one *can* technically keep reading in the latter</span></div>
<div class="line"><a id="l00383" name="l00383"></a><span class="lineno">  383</span><span class="comment"> *         case, in that the underlying connection is still connected potentially.  However, formally, behavior is</span></div>
<div class="line"><a id="l00384" name="l00384"></a><span class="lineno">  384</span><span class="comment"> *         undefined if one reads more subsequently.  Informally: if the other side has violated protocol</span></div>
<div class="line"><a id="l00385" name="l00385"></a><span class="lineno">  385</span><span class="comment"> *         expectations -- or if your side has violated expectations on proper reading (see below section on that) --</span></div>
<div class="line"><a id="l00386" name="l00386"></a><span class="lineno">  386</span><span class="comment"> *         then neither side can be trusted to recover logical consistency and must abandon the connection.</span></div>
<div class="line"><a id="l00387" name="l00387"></a><span class="lineno">  387</span><span class="comment"> *     - `E == operation_aborted` is not possible.</span></div>
<div class="line"><a id="l00388" name="l00388"></a><span class="lineno">  388</span><span class="comment"> *</span></div>
<div class="line"><a id="l00389" name="l00389"></a><span class="lineno">  389</span><span class="comment"> * Items are extensively logged on `*logger_ptr`, and we follow the normal best practices to avoid verbose messages</span></div>
<div class="line"><a id="l00390" name="l00390"></a><span class="lineno">  390</span><span class="comment"> * at the severities strictly higher than `TRACE`.  In particular, any error is logged as a `WARNING`, so in particular</span></div>
<div class="line"><a id="l00391" name="l00391"></a><span class="lineno">  391</span><span class="comment"> * there&#39;s no need for caller to specifically log about the details of a non-false `E`.</span></div>
<div class="line"><a id="l00392" name="l00392"></a><span class="lineno">  392</span><span class="comment"> * (If this is still too slow, you may use the `flow::log::Config::this_thread_verbosity_override_auto()` to</span></div>
<div class="line"><a id="l00393" name="l00393"></a><span class="lineno">  393</span><span class="comment"> * temporarily, in that thread only, disable logging.  This is quite easy and performant.)</span></div>
<div class="line"><a id="l00394" name="l00394"></a><span class="lineno">  394</span><span class="comment"> *</span></div>
<div class="line"><a id="l00395" name="l00395"></a><span class="lineno">  395</span><span class="comment"> * ### Blob/handle semantics ###</span></div>
<div class="line"><a id="l00396" name="l00396"></a><span class="lineno">  396</span><span class="comment"> * Non-blocking stream-blob-send/receive semantics must be familiar to you, such as from TCP and otherwise.</span></div>
<div class="line"><a id="l00397" name="l00397"></a><span class="lineno">  397</span><span class="comment"> * By adding native handles (further, just *handles*) as accompaniment to this system, non-trivial -- arguably</span></div>
<div class="line"><a id="l00398" name="l00398"></a><span class="lineno">  398</span><span class="comment"> * subtle -- questions are raised about how it all works together.  The central question is, perhaps, if I ask to send</span></div>
<div class="line"><a id="l00399" name="l00399"></a><span class="lineno">  399</span><span class="comment"> * N bytes and handle S, non-blockingly, what are the various possibilities for sending less than N bytes of the blob</span></div>
<div class="line"><a id="l00400" name="l00400"></a><span class="lineno">  400</span><span class="comment"> * and whether S is also sent?  Conversely, how will receiving on the other side work?  The following describes those</span></div>
<div class="line"><a id="l00401" name="l00401"></a><span class="lineno">  401</span><span class="comment"> * semantics and *mandates* how to properly handle it.  Not following these formally leads to undefined behavior.</span></div>
<div class="line"><a id="l00402" name="l00402"></a><span class="lineno">  402</span><span class="comment"> * (Informally, for the tested OS versions, it is possible to count on certain additional behaviors; but trying to do</span></div>
<div class="line"><a id="l00403" name="l00403"></a><span class="lineno">  403</span><span class="comment"> * so is (1) prone to spurious changes and breakage in different OS versions and types, since much of this is</span></div>
<div class="line"><a id="l00404" name="l00404"></a><span class="lineno">  404</span><span class="comment"> * undocumented; and (2) will probably just make your life *more* difficult anyway, not less.  Honestly I (ygoldfel)</span></div>
<div class="line"><a id="l00405" name="l00405"></a><span class="lineno">  405</span><span class="comment"> * designed it for ease of following as opposed to exactly maximal freedom of capability.  So... just follow these.)</span></div>
<div class="line"><a id="l00406" name="l00406"></a><span class="lineno">  406</span><span class="comment"> *</span></div>
<div class="line"><a id="l00407" name="l00407"></a><span class="lineno">  407</span><span class="comment"> * Firstly, as already stated, it is not possible to try sending a handle sans a blob; and it is not possible</span></div>
<div class="line"><a id="l00408" name="l00408"></a><span class="lineno">  408</span><span class="comment"> * to receive a handle sans a blob.  (The converse is a regular non-blocking blob write or receive op.)</span></div>
<div class="line"><a id="l00409" name="l00409"></a><span class="lineno">  409</span><span class="comment"> *</span></div>
<div class="line"><a id="l00410" name="l00410"></a><span class="lineno">  410</span><span class="comment"> * Secondly, one must think of the handle as associated with *exactly the first byte* of the blob arg to the</span></div>
<div class="line"><a id="l00411" name="l00411"></a><span class="lineno">  411</span><span class="comment"> * write call (nb_write_some_with_native_handle()).  Similarly, one must think of the handle as associated with</span></div>
<div class="line"><a id="l00412" name="l00412"></a><span class="lineno">  412</span><span class="comment"> * *exactly the first byte* of the blob arg to the read call (nb_read_some_with_native_handle()).  Moreover,</span></div>
<div class="line"><a id="l00413" name="l00413"></a><span class="lineno">  413</span><span class="comment"> * known OS make certain not-well-documented assumptions about message lengths.  What does this all</span></div>
<div class="line"><a id="l00414" name="l00414"></a><span class="lineno">  414</span><span class="comment"> * mean in practice?</span></div>
<div class="line"><a id="l00415" name="l00415"></a><span class="lineno">  415</span><span class="comment"> *   - You may design your protocol however you want, except the following requirement: Define a</span></div>
<div class="line"><a id="l00416" name="l00416"></a><span class="lineno">  416</span><span class="comment"> *     *handle-containing message* as a combination of a blob of 1+ bytes of some known (on both sides, at the time</span></div>
<div class="line"><a id="l00417" name="l00417"></a><span class="lineno">  417</span><span class="comment"> *     of both sending and receipt) length N *and* exactly *one* handle.  You must aim to send this message and</span></div>
<div class="line"><a id="l00418" name="l00418"></a><span class="lineno">  418</span><span class="comment"> *     receive it exactly as sent, meaning with message boundaries respected.  (To be clear, you&#39;re free to use</span></div>
<div class="line"><a id="l00419" name="l00419"></a><span class="lineno">  419</span><span class="comment"> *     any technique to make N known on both sides; e.g., it may be a constant; or it may be passed in a previous</span></div>
<div class="line"><a id="l00420" name="l00420"></a><span class="lineno">  420</span><span class="comment"> *     message.  However, it&#39;s not compatible with using a sentinel alone, as then N is unknown.)</span></div>
<div class="line"><a id="l00421" name="l00421"></a><span class="lineno">  421</span><span class="comment"> *     - You must only transmit handles as part of handle-containing messages.  Anything else is undefined behavior.</span></div>
<div class="line"><a id="l00422" name="l00422"></a><span class="lineno">  422</span><span class="comment"> *   - Let M be a given handle-containing message with blob B of size N; and handle H.</span></div>
<div class="line"><a id="l00423" name="l00423"></a><span class="lineno">  423</span><span class="comment"> *     Let a *write op* be nb_write_some_with_native_handle() (or an async_write_with_native_handle() based on it).</span></div>
<div class="line"><a id="l00424" name="l00424"></a><span class="lineno">  424</span><span class="comment"> *     - You shall attempt one write op for the blob B of size N together with handle H.  Do *not* intermix it with any</span></div>
<div class="line"><a id="l00425" name="l00425"></a><span class="lineno">  425</span><span class="comment"> *       other bytes or handles.</span></div>
<div class="line"><a id="l00426" name="l00426"></a><span class="lineno">  426</span><span class="comment"> *       - In the non-blocking write op case (nb_write_some_with_native_handle()) it may yield successfully sending</span></div>
<div class="line"><a id="l00427" name="l00427"></a><span class="lineno">  427</span><span class="comment"> *         N&#39; bytes, where 1 &lt;= N&#39; &lt; N.  This means the handle was successfully sent also, because the handle is</span></div>
<div class="line"><a id="l00428" name="l00428"></a><span class="lineno">  428</span><span class="comment"> *         associated with the *first byte* of the write -- and read -- op.  If this happens, don&#39;t worry about it;</span></div>
<div class="line"><a id="l00429" name="l00429"></a><span class="lineno">  429</span><span class="comment"> *         continue with the rest of the protocol, including sending at least the remaining (N - N&#39;) bytes of M.</span></div>
<div class="line"><a id="l00430" name="l00430"></a><span class="lineno">  430</span><span class="comment"> *     - On the receiver side, you must symmetrically execute the read op (nb_read_some_with_native_handle(), perhaps</span></div>
<div class="line"><a id="l00431" name="l00431"></a><span class="lineno">  431</span><span class="comment"> *       after a `Peer_socket::async_wait()`) to attempt receipt of all of M, including supplying a target</span></div>
<div class="line"><a id="l00432" name="l00432"></a><span class="lineno">  432</span><span class="comment"> *       blob of exactly N bytes -- without mixing with any other bytes or handles.  The &quot;hard&quot; part of this is mainly</span></div>
<div class="line"><a id="l00433" name="l00433"></a><span class="lineno">  433</span><span class="comment"> *       to avoid having the previous read op &quot;cut into&quot; M.</span></div>
<div class="line"><a id="l00434" name="l00434"></a><span class="lineno">  434</span><span class="comment"> *       - (Informally, a common-sense way to do it just make</span></div>
<div class="line"><a id="l00435" name="l00435"></a><span class="lineno">  435</span><span class="comment"> *         your protocol message-based, such that the length of the next message is always known on either side.)</span></div>
<div class="line"><a id="l00436" name="l00436"></a><span class="lineno">  436</span><span class="comment"> *       - Again, if the nb_read_some_with_native_handle() call returns N&#39;, where 1 &lt;= N&#39; &lt; N, then no worries.</span></div>
<div class="line"><a id="l00437" name="l00437"></a><span class="lineno">  437</span><span class="comment"> *         The handle S *will* have been successfully received, being associated with byte 1 of M.</span></div>
<div class="line"><a id="l00438" name="l00438"></a><span class="lineno">  438</span><span class="comment"> *         Keep reading the rest of M (namely, the remaining (N - N&#39;) bytes of the blob B) with more read op(s).</span></div>
<div class="line"><a id="l00439" name="l00439"></a><span class="lineno">  439</span><span class="comment"> *       - (To put a fine point on it: In known Linux versions as of this writing, if you do try to read-op N&#39; bytes</span></div>
<div class="line"><a id="l00440" name="l00440"></a><span class="lineno">  440</span><span class="comment"> *         having executed write-op with N&#39;&#39; bytes, where N&#39;&#39; &gt; N&#39;, then you may observe very strange, undefined</span></div>
<div class="line"><a id="l00441" name="l00441"></a><span class="lineno">  441</span><span class="comment"> *         (albeit non-crashy), behavior such as S disappearing or replacing a following-message handle S&#39;.  Don&#39;t.)</span></div>
<div class="line"><a id="l00442" name="l00442"></a><span class="lineno">  442</span><span class="comment"> *</span></div>
<div class="line"><a id="l00443" name="l00443"></a><span class="lineno">  443</span><span class="comment"> * That is admittedly many words, but really in practice it&#39;s fairly natural and simple to design a message-based</span></div>
<div class="line"><a id="l00444" name="l00444"></a><span class="lineno">  444</span><span class="comment"> * protocol and implementation around it.  Just do follow these; I merely wanted to be complete.</span></div>
<div class="line"><a id="l00445" name="l00445"></a><span class="lineno">  445</span><span class="comment"> *</span></div>
<div class="line"><a id="l00446" name="l00446"></a><span class="lineno">  446</span><span class="comment"> * ### Features of `Peer_socket::read_some()` not provided here ###</span></div>
<div class="line"><a id="l00447" name="l00447"></a><span class="lineno">  447</span><span class="comment"> * We have (consciously) made these concessions: ...see nb_write_some_with_native_handle() doc header.  All of the</span></div>
<div class="line"><a id="l00448" name="l00448"></a><span class="lineno">  448</span><span class="comment"> * listed omitted features have common-sense counterparts in the case of the present function.</span></div>
<div class="line"><a id="l00449" name="l00449"></a><span class="lineno">  449</span><span class="comment"> *</span></div>
<div class="line"><a id="l00450" name="l00450"></a><span class="lineno">  450</span><span class="comment"> * ### Advanced feature on top of `Peer_socket::read_some()` ###</span></div>
<div class="line"><a id="l00451" name="l00451"></a><span class="lineno">  451</span><span class="comment"> * Lastly, `Peer_socket::receive()` is identical to `Peer_socket::read_some()` but adds an overload wherein one can</span></div>
<div class="line"><a id="l00452" name="l00452"></a><span class="lineno">  452</span><span class="comment"> * pass in a (largely unportable, I (ygoldfel) think) `message_flags` bit mask.  We *do* provide a close cousin of this</span></div>
<div class="line"><a id="l00453" name="l00453"></a><span class="lineno">  453</span><span class="comment"> * feature via the (optional as of this writing) arg `native_recvmsg_flags`.  (Rationale: We specifically omitted it</span></div>
<div class="line"><a id="l00454" name="l00454"></a><span class="lineno">  454</span><span class="comment"> * in nb_write_some_with_native_handle(); yet add it here because the value `MSG_CMSG_CLOEXEC` has specific utility.)</span></div>
<div class="line"><a id="l00455" name="l00455"></a><span class="lineno">  455</span><span class="comment"> * One may override the default (`0`) by supplying any value one would supply as the `int flags` arg of Linux&#39;s</span></div>
<div class="line"><a id="l00456" name="l00456"></a><span class="lineno">  456</span><span class="comment"> * `recvmsg()` (see `man recvmsg`).  As one can see in the `man` page, this is a bit mask or ORed values.  Formally,</span></div>
<div class="line"><a id="l00457" name="l00457"></a><span class="lineno">  457</span><span class="comment"> * however, the only value supported (does not lead to undefined behavior) is `MSG_CMSG_CLOEXEC` (please read its docs</span></div>
<div class="line"><a id="l00458" name="l00458"></a><span class="lineno">  458</span><span class="comment"> * elsewhere, but in summary it sets the close-on-`exec` bit of any non-null received `*target_payload_blob`).</span></div>
<div class="line"><a id="l00459" name="l00459"></a><span class="lineno">  459</span><span class="comment"> * Informally: that flag may be important for one&#39;s application; so we provide for it; however beyond that one please</span></div>
<div class="line"><a id="l00460" name="l00460"></a><span class="lineno">  460</span><span class="comment"> * refer to the reasoning regarding not supporting `message_flags` in nb_write_some_with_native_handle() as explained</span></div>
<div class="line"><a id="l00461" name="l00461"></a><span class="lineno">  461</span><span class="comment"> * in its doc header.</span></div>
<div class="line"><a id="l00462" name="l00462"></a><span class="lineno">  462</span><span class="comment"> *</span></div>
<div class="line"><a id="l00463" name="l00463"></a><span class="lineno">  463</span><span class="comment"> * ### Rationale ###</span></div>
<div class="line"><a id="l00464" name="l00464"></a><span class="lineno">  464</span><span class="comment"> * This function exists because... [text omitted -- same reasoning as similar rationale for</span></div>
<div class="line"><a id="l00465" name="l00465"></a><span class="lineno">  465</span><span class="comment"> * async_write_with_native_handle()].</span></div>
<div class="line"><a id="l00466" name="l00466"></a><span class="lineno">  466</span><span class="comment"> *</span></div>
<div class="line"><a id="l00467" name="l00467"></a><span class="lineno">  467</span><span class="comment"> * @param logger_ptr</span></div>
<div class="line"><a id="l00468" name="l00468"></a><span class="lineno">  468</span><span class="comment"> *        Logger to use for subsequently logging.</span></div>
<div class="line"><a id="l00469" name="l00469"></a><span class="lineno">  469</span><span class="comment"> * @param peer_socket</span></div>
<div class="line"><a id="l00470" name="l00470"></a><span class="lineno">  470</span><span class="comment"> *        Pointer to stream socket.  If it is not connected, or otherwise unsuitable, behavior is identical to</span></div>
<div class="line"><a id="l00471" name="l00471"></a><span class="lineno">  471</span><span class="comment"> *        attempting `read_some()` on such a socket.  If null behavior is undefined (assertion may trip).</span></div>
<div class="line"><a id="l00472" name="l00472"></a><span class="lineno">  472</span><span class="comment"> * @param target_payload_hndl</span></div>
<div class="line"><a id="l00473" name="l00473"></a><span class="lineno">  473</span><span class="comment"> *        The native handle wrapper into which to copy the received handle; it shall be set such that</span></div>
<div class="line"><a id="l00474" name="l00474"></a><span class="lineno">  474</span><span class="comment"> *        `target_payload_hndl-&gt;null() == true` if the read-op returned 1+ (succeeded), but those bytes were not</span></div>
<div class="line"><a id="l00475" name="l00475"></a><span class="lineno">  475</span><span class="comment"> *        accompanied by any native handle.  It shall also be thus set if 0 is returned (indicating error</span></div>
<div class="line"><a id="l00476" name="l00476"></a><span class="lineno">  476</span><span class="comment"> *        including would-block and fatal errors).</span></div>
<div class="line"><a id="l00477" name="l00477"></a><span class="lineno">  477</span><span class="comment"> * @param target_payload_blob</span></div>
<div class="line"><a id="l00478" name="l00478"></a><span class="lineno">  478</span><span class="comment"> *        The buffer into which to write received blob data, namely up to `target_payload_blob-&gt;size()` bytes.</span></div>
<div class="line"><a id="l00479" name="l00479"></a><span class="lineno">  479</span><span class="comment"> *        If null, or the size is not positive, behiavor is undefined (assertion may trip).</span></div>
<div class="line"><a id="l00480" name="l00480"></a><span class="lineno">  480</span><span class="comment"> *        Reiterating the above outcome semantics: Either there is no error, and then the `N` returned will be 1+; or a</span></div>
<div class="line"><a id="l00481" name="l00481"></a><span class="lineno">  481</span><span class="comment"> *        truthy `Error_code` is returned either via the out-arg or via thrown `Runtime_error`, and in the former case</span></div>
<div class="line"><a id="l00482" name="l00482"></a><span class="lineno">  482</span><span class="comment"> *        0 is returned.</span></div>
<div class="line"><a id="l00483" name="l00483"></a><span class="lineno">  483</span><span class="comment"> * @param err_code</span></div>
<div class="line"><a id="l00484" name="l00484"></a><span class="lineno">  484</span><span class="comment"> *        See `flow::Error_code` docs for error reporting semantics.  #Error_code generated:</span></div>
<div class="line"><a id="l00485" name="l00485"></a><span class="lineno">  485</span><span class="comment"> *        `boost::asio::error::would_block` (socket not writable, likely because other side isn&#39;t reading ASAP),</span></div>
<div class="line"><a id="l00486" name="l00486"></a><span class="lineno">  486</span><span class="comment"> *        ipc::transport::error::Code::S_LOW_LVL_UNEXPECTED_STREAM_PAYLOAD_BEYOND_HNDL</span></div>
<div class="line"><a id="l00487" name="l00487"></a><span class="lineno">  487</span><span class="comment"> *        (strictly more than 1 handle detected in the read-op, but we support only 1 at this time; see above;</span></div>
<div class="line"><a id="l00488" name="l00488"></a><span class="lineno">  488</span><span class="comment"> *        maybe they didn&#39;t use above write-op function(s) and/or didn&#39;t follow anti-straddling suggestion above),</span></div>
<div class="line"><a id="l00489" name="l00489"></a><span class="lineno">  489</span><span class="comment"> *        other system codes (see notes above in the outcome discussion).</span></div>
<div class="line"><a id="l00490" name="l00490"></a><span class="lineno">  490</span><span class="comment"> * @param message_flags</span></div>
<div class="line"><a id="l00491" name="l00491"></a><span class="lineno">  491</span><span class="comment"> *        See boost.asio `Peer_socket::receive()` overload with this arg.</span></div>
<div class="line"><a id="l00492" name="l00492"></a><span class="lineno">  492</span><span class="comment"> * @return 0 if non-null `err_code` and truthy resulting `*err_code`, and hence no bytes or the handle was sent; 1+</span></div>
<div class="line"><a id="l00493" name="l00493"></a><span class="lineno">  493</span><span class="comment"> *         if that number of bytes were sent plus the native handle (and hence falsy `*err_code` if non-null).</span></div>
<div class="line"><a id="l00494" name="l00494"></a><span class="lineno">  494</span><span class="comment"> *</span></div>
<div class="line"><a id="l00495" name="l00495"></a><span class="lineno">  495</span><span class="comment"> * @internal</span></div>
<div class="line"><a id="l00496" name="l00496"></a><span class="lineno">  496</span><span class="comment"> * ### Implementation notes ###</span></div>
<div class="line"><a id="l00497" name="l00497"></a><span class="lineno">  497</span><span class="comment"> * Where does the content of &quot;Blob/handle semantics&quot; originate?  Answer: Good question, as reading `man` pages to do</span></div>
<div class="line"><a id="l00498" name="l00498"></a><span class="lineno">  498</span><span class="comment"> * with `sendmsg()/recvmsg()/cmsg/unix`, etc., gives hints but really is incomplete and certainly not formally complete.</span></div>
<div class="line"><a id="l00499" name="l00499"></a><span class="lineno">  499</span><span class="comment"> * Without such a description, one can guess at how `SOL_SOCKET/SCM_RIGHTS` (sending of FDs along with blobs) might work</span></div>
<div class="line"><a id="l00500" name="l00500"></a><span class="lineno">  500</span><span class="comment"> * but not conclusively.  I (ygoldfel) nevertheless actually correctly developed the relevant conclusions via common</span></div>
<div class="line"><a id="l00501" name="l00501"></a><span class="lineno">  501</span><span class="comment"> * sense/experience... and *later* confirmed them by reading kernel source and the delightfully helpful</span></div>
<div class="line"><a id="l00502" name="l00502"></a><span class="lineno">  502</span><span class="comment"> * write-up at [ https://gist.github.com/kentonv/bc7592af98c68ba2738f4436920868dc ] (Googled &quot;SCM_RIGHTS gist&quot;).</span></div>
<div class="line"><a id="l00503" name="l00503"></a><span class="lineno">  503</span><span class="comment"> * Reading these may give the code inspector/maintainer (you?) more peace of mind.  Basically, though, the key gist</span></div>
<div class="line"><a id="l00504" name="l00504"></a><span class="lineno">  504</span><span class="comment"> * is:</span></div>
<div class="line"><a id="l00505" name="l00505"></a><span class="lineno">  505</span><span class="comment"> *   - The handle(s) are associated with byte 1 of the blob given to the `sendmsg()` call containing those handle(s).</span></div>
<div class="line"><a id="l00506" name="l00506"></a><span class="lineno">  506</span><span class="comment"> *     For this reason, to avoid protocol chaos, you should send each given handle with the same &quot;synchronized&quot; byte</span></div>
<div class="line"><a id="l00507" name="l00507"></a><span class="lineno">  507</span><span class="comment"> *     on both sides.</span></div>
<div class="line"><a id="l00508" name="l00508"></a><span class="lineno">  508</span><span class="comment"> *   - The length of that blob similarly matters -- which is not normal, as otherwise message boundaries are *not*</span></div>
<div class="line"><a id="l00509" name="l00509"></a><span class="lineno">  509</span><span class="comment"> *     normally maintained for stream connections -- and for this reason the read op must accept a result into a blob</span></div>
<div class="line"><a id="l00510" name="l00510"></a><span class="lineno">  510</span><span class="comment"> *     of at *least* the same same size as the corresponding write op.  (For simplicity and other reasons my</span></div>
<div class="line"><a id="l00511" name="l00511"></a><span class="lineno">  511</span><span class="comment"> *     instructions say it should just be equal.)</span></div>
<div class="line"><a id="l00512" name="l00512"></a><span class="lineno">  512</span><span class="comment"> *</span></div>
<div class="line"><a id="l00513" name="l00513"></a><span class="lineno">  513</span><span class="comment"> * Lastly, I note that potentially using `SOCK_SEQPACKET` (which purports to conserve message boundaries at all times)</span></div>
<div class="line"><a id="l00514" name="l00514"></a><span class="lineno">  514</span><span class="comment"> * instead of `SOCK_STREAM` (which we use) might remove all ambiguity.  On the other hand it&#39;s barely documented itself.</span></div>
<div class="line"><a id="l00515" name="l00515"></a><span class="lineno">  515</span><span class="comment"> * The rationale for the decision to use `SOCK_STREAM` is discussed elsewhere; this note is to reassure that I</span></div>
<div class="line"><a id="l00516" name="l00516"></a><span class="lineno">  516</span><span class="comment"> * (ygoldfel) don&#39;t quite find the above complexity reason enough to switch to `SOCK_SEQPACKET`.</span></div>
<div class="line"><a id="l00517" name="l00517"></a><span class="lineno">  517</span><span class="comment"> */</span></div>
<div class="line"><a id="l00518" name="l00518"></a><span class="lineno">  518</span><span class="keywordtype">size_t</span> <a class="code hl_function" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a9ae82b2a234b218704c62fb616d6fcc5">nb_read_some_with_native_handle</a>(flow::log::Logger* logger_ptr,</div>
<div class="line"><a id="l00519" name="l00519"></a><span class="lineno">  519</span>                                       <a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">Peer_socket</a>* peer_socket,</div>
<div class="line"><a id="l00520" name="l00520"></a><span class="lineno">  520</span>                                       <a class="code hl_struct" href="structipc_1_1util_1_1Native__handle.html">Native_handle</a>* target_payload_hndl,</div>
<div class="line"><a id="l00521" name="l00521"></a><span class="lineno">  521</span>                                       <span class="keyword">const</span> <a class="code hl_typedef" href="namespaceipc_1_1util.html#a6cb62ae434900f3a8915b33ec5d61a96">util::Blob_mutable</a>&amp; target_payload_blob,</div>
<div class="line"><a id="l00522" name="l00522"></a><span class="lineno">  522</span>                                       <a class="code hl_typedef" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">Error_code</a>* err_code,</div>
<div class="line"><a id="l00523" name="l00523"></a><span class="lineno">  523</span>                                       <span class="keywordtype">int</span> message_flags = 0);</div>
<div class="line"><a id="l00524" name="l00524"></a><span class="lineno">  524</span><span class="comment"></span> </div>
<div class="line"><a id="l00525" name="l00525"></a><span class="lineno">  525</span><span class="comment">/**</span></div>
<div class="line"><a id="l00526" name="l00526"></a><span class="lineno">  526</span><span class="comment"> * boost.asio extension similar to</span></div>
<div class="line"><a id="l00527" name="l00527"></a><span class="lineno">  527</span><span class="comment"> * `boost::asio::async_read(Peer_socket&amp;, Blob_mutable, Task_err_sz)` with the difference that the target</span></div>
<div class="line"><a id="l00528" name="l00528"></a><span class="lineno">  528</span><span class="comment"> * buffer (util::Blob_mutable) is determined by calling the arg-supplied function at the time when at least 1 byte</span></div>
<div class="line"><a id="l00529" name="l00529"></a><span class="lineno">  529</span><span class="comment"> * is available to read, instead of the buffer being given direcly as an arg.  By determining where to target when</span></div>
<div class="line"><a id="l00530" name="l00530"></a><span class="lineno">  530</span><span class="comment"> * there are actual data available, one can avoid unnecessary copying in the meantime; among other applications.</span></div>
<div class="line"><a id="l00531" name="l00531"></a><span class="lineno">  531</span><span class="comment"> *</span></div>
<div class="line"><a id="l00532" name="l00532"></a><span class="lineno">  532</span><span class="comment"> * ### Behavior ###</span></div>
<div class="line"><a id="l00533" name="l00533"></a><span class="lineno">  533</span><span class="comment"> * boost.asio&#39;s `async_read()` free function is generically capable of receiving into a sequence of 1+ buffers on</span></div>
<div class="line"><a id="l00534" name="l00534"></a><span class="lineno">  534</span><span class="comment"> * a connected stream socket, continuing until either the entire sequence is fully filled to the byte; or an error (not</span></div>
<div class="line"><a id="l00535" name="l00535"></a><span class="lineno">  535</span><span class="comment"> * counting would-block, which just means keep trying to make progress when possible).  We act exactly the same with</span></div>
<div class="line"><a id="l00536" name="l00536"></a><span class="lineno">  536</span><span class="comment"> * the following essential differences being the exceptions:</span></div>
<div class="line"><a id="l00537" name="l00537"></a><span class="lineno">  537</span><span class="comment"> *   - The target buffer is determined once system indicates at least 1 byte of data is available to actually read</span></div>
<div class="line"><a id="l00538" name="l00538"></a><span class="lineno">  538</span><span class="comment"> *     off socket; it&#39;s not supplied as an arg.</span></div>
<div class="line"><a id="l00539" name="l00539"></a><span class="lineno">  539</span><span class="comment"> *     - To determine it, we call `target_payload_blob_func()` which must return the util::Blob_mutable.</span></div>
<div class="line"><a id="l00540" name="l00540"></a><span class="lineno">  540</span><span class="comment"> *   - One can cancel the (rest of the) operation via `should_interrupt_func()`.  This is called just after</span></div>
<div class="line"><a id="l00541" name="l00541"></a><span class="lineno">  541</span><span class="comment"> *     being internally informed the socket is ready for reading, so just before the 1st `target_payload_blob_func()`</span></div>
<div class="line"><a id="l00542" name="l00542"></a><span class="lineno">  542</span><span class="comment"> *     call, and ahead of each subsequent burst of non-blockingly-available bytes as well.</span></div>
<div class="line"><a id="l00543" name="l00543"></a><span class="lineno">  543</span><span class="comment"> *     If it returns `true`, then the operation is canceled; the target buffer (if it has even been determined)</span></div>
<div class="line"><a id="l00544" name="l00544"></a><span class="lineno">  544</span><span class="comment"> *     is not written to further; and `on_rcvd_or_error()` is never invoked.  Note that `should_interrupt_func()`</span></div>
<div class="line"><a id="l00545" name="l00545"></a><span class="lineno">  545</span><span class="comment"> *     may be called ages after whatever outside interrupt-causing condition has occurred; typically your</span></div>
<div class="line"><a id="l00546" name="l00546"></a><span class="lineno">  546</span><span class="comment"> *     impl would merely check for that condition being the case (e.g., &quot;have we encountered idle timeout earlier?&quot;).</span></div>
<div class="line"><a id="l00547" name="l00547"></a><span class="lineno">  547</span><span class="comment"> *   - Once the handler is called, its signature is similar (`Error_code`, `size_t` of bytes received) but with one</span></div>
<div class="line"><a id="l00548" name="l00548"></a><span class="lineno">  548</span><span class="comment"> *     added arg, `const Blob_mutable&amp; target_payload_blob`, which is simply a copy of the light-weight object returned</span></div>
<div class="line"><a id="l00549" name="l00549"></a><span class="lineno">  549</span><span class="comment"> *     per preceding bullet point.</span></div>
<div class="line"><a id="l00550" name="l00550"></a><span class="lineno">  550</span><span class="comment"> *     - It is possible `target_payload_blob_func()` is never called; in this case the error code shall be truthy, and</span></div>
<div class="line"><a id="l00551" name="l00551"></a><span class="lineno">  551</span><span class="comment"> *       the reported size received shall be 0.  In this case disregard the `target_payload_blob` value received; it</span></div>
<div class="line"><a id="l00552" name="l00552"></a><span class="lineno">  552</span><span class="comment"> *       shall be a null/empty blob.</span></div>
<div class="line"><a id="l00553" name="l00553"></a><span class="lineno">  553</span><span class="comment"> *     - The returned util::Blob_mutable may have `.size() == 0`.  In this case we shall perform no actual read;</span></div>
<div class="line"><a id="l00554" name="l00554"></a><span class="lineno">  554</span><span class="comment"> *       and will simply invoke the handler immediately upon detecting this; the reported error code shall be falsy,</span></div>
<div class="line"><a id="l00555" name="l00555"></a><span class="lineno">  555</span><span class="comment"> *       and the reported size received shall be 0.</span></div>
<div class="line"><a id="l00556" name="l00556"></a><span class="lineno">  556</span><span class="comment"> *   - If `peer_socket-&gt;non_blocking() == false` at entry to this function, it shall be `true`</span></div>
<div class="line"><a id="l00557" name="l00557"></a><span class="lineno">  557</span><span class="comment"> *     at entry to the handler, except it *might* be false if the handler receives a truthy `Error_code`.</span></div>
<div class="line"><a id="l00558" name="l00558"></a><span class="lineno">  558</span><span class="comment"> *     (Informally: In that case, the connection should be considered hosed in any case and must not be used for</span></div>
<div class="line"><a id="l00559" name="l00559"></a><span class="lineno">  559</span><span class="comment"> *     traffic.)</span></div>
<div class="line"><a id="l00560" name="l00560"></a><span class="lineno">  560</span><span class="comment"> *   - More logging, as a convenience.</span></div>
<div class="line"><a id="l00561" name="l00561"></a><span class="lineno">  561</span><span class="comment"> *</span></div>
<div class="line"><a id="l00562" name="l00562"></a><span class="lineno">  562</span><span class="comment"> * It is otherwise identical... but certain aspects of `async_read()` are not included in the present</span></div>
<div class="line"><a id="l00563" name="l00563"></a><span class="lineno">  563</span><span class="comment"> * function, however, though merely because they were not necessary as of this writing and hence excluded for</span></div>
<div class="line"><a id="l00564" name="l00564"></a><span class="lineno">  564</span><span class="comment"> * simplicity; these are formally described below.</span></div>
<div class="line"><a id="l00565" name="l00565"></a><span class="lineno">  565</span><span class="comment"> *</span></div>
<div class="line"><a id="l00566" name="l00566"></a><span class="lineno">  566</span><span class="comment"> * ### Thread safety ###</span></div>
<div class="line"><a id="l00567" name="l00567"></a><span class="lineno">  567</span><span class="comment"> * Like `async_read()`, the (synchronous) call is not thread-safe with respect to the given `*peer_socket` against</span></div>
<div class="line"><a id="l00568" name="l00568"></a><span class="lineno">  568</span><span class="comment"> * all/most calls operating on the same object.  Moreover, this extends to the brief time period when the first byte</span></div>
<div class="line"><a id="l00569" name="l00569"></a><span class="lineno">  569</span><span class="comment"> * is available.  Since there is no way of knowing when that might be, essentially you should consider this entire</span></div>
<div class="line"><a id="l00570" name="l00570"></a><span class="lineno">  570</span><span class="comment"> * async op as not safe for concurrent execution with any/most calls operating on the same `Peer_socket`, in the</span></div>
<div class="line"><a id="l00571" name="l00571"></a><span class="lineno">  571</span><span class="comment"> * time period [entry to async_read_with_target_func(), entry to `target_payload_blob_func()`].</span></div>
<div class="line"><a id="l00572" name="l00572"></a><span class="lineno">  572</span><span class="comment"> *</span></div>
<div class="line"><a id="l00573" name="l00573"></a><span class="lineno">  573</span><span class="comment"> * Informally, as with `async_read()`, it is unwise to do anything with `*peer_socket` upon calling the present</span></div>
<div class="line"><a id="l00574" name="l00574"></a><span class="lineno">  574</span><span class="comment"> * function through when the handler begins executing.</span></div>
<div class="line"><a id="l00575" name="l00575"></a><span class="lineno">  575</span><span class="comment"> *</span></div>
<div class="line"><a id="l00576" name="l00576"></a><span class="lineno">  576</span><span class="comment"> * `on_rcvd_or_error()` is invoked fully respecting any possible executor (typically none, else a `Strand`) associated</span></div>
<div class="line"><a id="l00577" name="l00577"></a><span class="lineno">  577</span><span class="comment"> * (via `bind_executor()` usually) with it.</span></div>
<div class="line"><a id="l00578" name="l00578"></a><span class="lineno">  578</span><span class="comment"> *</span></div>
<div class="line"><a id="l00579" name="l00579"></a><span class="lineno">  579</span><span class="comment"> * However `should_interrupt_func()` and `target_payload_blob()` are invoked directly via</span></div>
<div class="line"><a id="l00580" name="l00580"></a><span class="lineno">  580</span><span class="comment"> * `peer_socket-&gt;get_executor()`, and any potential associated executor on these functions themselves is</span></div>
<div class="line"><a id="l00581" name="l00581"></a><span class="lineno">  581</span><span class="comment"> * ignored.  (This is the case simply because there was no internal-to-rest-of-Flow-IPC use case for acting otherwise;</span></div>
<div class="line"><a id="l00582" name="l00582"></a><span class="lineno">  582</span><span class="comment"> * but it&#39;s conceivable to implement it later, albeit at the cost of some more processor cycles used.)</span></div>
<div class="line"><a id="l00583" name="l00583"></a><span class="lineno">  583</span><span class="comment"> *</span></div>
<div class="line"><a id="l00584" name="l00584"></a><span class="lineno">  584</span><span class="comment"> * ### Features of `boost::asio::async_read()` not provided here ###</span></div>
<div class="line"><a id="l00585" name="l00585"></a><span class="lineno">  585</span><span class="comment"> * We have (consciously) made these concessions: ...see async_write_with_native_handle() doc header.  All of the</span></div>
<div class="line"><a id="l00586" name="l00586"></a><span class="lineno">  586</span><span class="comment"> * listed omitted features have common-sense counterparts in the case of the present function.  In addition:</span></div>
<div class="line"><a id="l00587" name="l00587"></a><span class="lineno">  587</span><span class="comment"> *  - `peer_socket` has to be a socket of that specific type, a local stream socket.  `async_write()` is templated on</span></div>
<div class="line"><a id="l00588" name="l00588"></a><span class="lineno">  588</span><span class="comment"> *    the socket type and will work with other connected stream sockets, notably TCP.</span></div>
<div class="line"><a id="l00589" name="l00589"></a><span class="lineno">  589</span><span class="comment"> *</span></div>
<div class="line"><a id="l00590" name="l00590"></a><span class="lineno">  590</span><span class="comment"> * ### Rationale ###</span></div>
<div class="line"><a id="l00591" name="l00591"></a><span class="lineno">  591</span><span class="comment"> * - This function exists because... [text omitted -- same reasoning as similar rationale for</span></div>
<div class="line"><a id="l00592" name="l00592"></a><span class="lineno">  592</span><span class="comment"> *   async_write_with_native_handle()].</span></div>
<div class="line"><a id="l00593" name="l00593"></a><span class="lineno">  593</span><span class="comment"> *   - Namely, though, the main thing is being able to delay targeting the data until that data are actually</span></div>
<div class="line"><a id="l00594" name="l00594"></a><span class="lineno">  594</span><span class="comment"> *     available to avoid internal copying in Native_socket_stream internals.</span></div>
<div class="line"><a id="l00595" name="l00595"></a><span class="lineno">  595</span><span class="comment"> *   - The `should_interrupt_func()` feature was necessary because Native_socket_stream internals has a condition</span></div>
<div class="line"><a id="l00596" name="l00596"></a><span class="lineno">  596</span><span class="comment"> *     where it is obligated to stop writing to the user buffer and return to them an overall in-pipe error:</span></div>
<div class="line"><a id="l00597" name="l00597"></a><span class="lineno">  597</span><span class="comment"> *     - idle timeout (no in-traffic for N time).</span></div>
<div class="line"><a id="l00598" name="l00598"></a><span class="lineno">  598</span><span class="comment"> *     - But the whole point of `async_read()` and therefore the present extension is to keep reading until all N</span></div>
<div class="line"><a id="l00599" name="l00599"></a><span class="lineno">  599</span><span class="comment"> *       bytes are here, or an error.  The aforementioned condition is, in a sense, the latter: an error; except</span></div>
<div class="line"><a id="l00600" name="l00600"></a><span class="lineno">  600</span><span class="comment"> *       it originates locally.  So `should_interrupt_func()` is a way to signal this.</span></div>
<div class="line"><a id="l00601" name="l00601"></a><span class="lineno">  601</span><span class="comment"> * - As noted, this sets non-blocking mode on `*peer_socket` if needed.  It does not &quot;undo&quot; this.  Why not?</span></div>
<div class="line"><a id="l00602" name="l00602"></a><span class="lineno">  602</span><span class="comment"> *   After all a clean op would act as if it has nothing to do with this.  Originally I (ygoldfel) did &quot;undo&quot; it.</span></div>
<div class="line"><a id="l00603" name="l00603"></a><span class="lineno">  603</span><span class="comment"> *   Then I decided otherwise for 2 reasons.  1, the situation where the &quot;undo&quot; itself fails made it ambiguous how to</span></div>
<div class="line"><a id="l00604" name="l00604"></a><span class="lineno">  604</span><span class="comment"> *   report this through the handler if everything had worked until then (unlikely as that is).  2, in coming up</span></div>
<div class="line"><a id="l00605" name="l00605"></a><span class="lineno">  605</span><span class="comment"> *   with a decent semantic approach for this annoying corner case that&#39;ll never really happen, and then thinking of</span></div>
<div class="line"><a id="l00606" name="l00606"></a><span class="lineno">  606</span><span class="comment"> *   how to document it, I realized the following practical truths:  `Peer_socket::non_blocking()` mode affects only</span></div>
<div class="line"><a id="l00607" name="l00607"></a><span class="lineno">  607</span><span class="comment"> *   the non-`async*()` ops on `Peer_socket`, and it&#39;s common to want those to be non-blocking in the first place,</span></div>
<div class="line"><a id="l00608" name="l00608"></a><span class="lineno">  608</span><span class="comment"> *   if one also feels the need to use `async*()` (like the present function).  So why jump through hoops for purity&#39;s</span></div>
<div class="line"><a id="l00609" name="l00609"></a><span class="lineno">  609</span><span class="comment"> *   sake?  Of course this can be changed later.</span></div>
<div class="line"><a id="l00610" name="l00610"></a><span class="lineno">  610</span><span class="comment"> *</span></div>
<div class="line"><a id="l00611" name="l00611"></a><span class="lineno">  611</span><span class="comment"> * @tparam Task_err_blob</span></div>
<div class="line"><a id="l00612" name="l00612"></a><span class="lineno">  612</span><span class="comment"> *         See `on_rcvd_or_error` arg.</span></div>
<div class="line"><a id="l00613" name="l00613"></a><span class="lineno">  613</span><span class="comment"> * @tparam Target_payload_blob_func</span></div>
<div class="line"><a id="l00614" name="l00614"></a><span class="lineno">  614</span><span class="comment"> *         See `target_payload_blob_func` arg.</span></div>
<div class="line"><a id="l00615" name="l00615"></a><span class="lineno">  615</span><span class="comment"> * @tparam Should_interrupt_func</span></div>
<div class="line"><a id="l00616" name="l00616"></a><span class="lineno">  616</span><span class="comment"> *         See `should_interrupt_func` arg.</span></div>
<div class="line"><a id="l00617" name="l00617"></a><span class="lineno">  617</span><span class="comment"> * @param logger_ptr</span></div>
<div class="line"><a id="l00618" name="l00618"></a><span class="lineno">  618</span><span class="comment"> *        Logger to use for subsequently logging.</span></div>
<div class="line"><a id="l00619" name="l00619"></a><span class="lineno">  619</span><span class="comment"> * @param peer_socket</span></div>
<div class="line"><a id="l00620" name="l00620"></a><span class="lineno">  620</span><span class="comment"> *        Pointer to stream socket.  If it is not connected, or otherwise unsuitable, behavior is identical to</span></div>
<div class="line"><a id="l00621" name="l00621"></a><span class="lineno">  621</span><span class="comment"> *        attempting `async_read()` on such a socket.  If null behavior is undefined (assertion may trip).</span></div>
<div class="line"><a id="l00622" name="l00622"></a><span class="lineno">  622</span><span class="comment"> * @param on_rcvd_or_error</span></div>
<div class="line"><a id="l00623" name="l00623"></a><span class="lineno">  623</span><span class="comment"> *        Handler to execute at most once on completion</span></div>
<div class="line"><a id="l00624" name="l00624"></a><span class="lineno">  624</span><span class="comment"> *        of the async op.  It is executed as if via `post(peer_socket-&gt;get_executor())`, fully respecting</span></div>
<div class="line"><a id="l00625" name="l00625"></a><span class="lineno">  625</span><span class="comment"> *        any executor bound to it (via `bind_executor()`, such as a strand).</span></div>
<div class="line"><a id="l00626" name="l00626"></a><span class="lineno">  626</span><span class="comment"> *        It shall be passed, in this order, `Error_code` and a value equal to the one returned by</span></div>
<div class="line"><a id="l00627" name="l00627"></a><span class="lineno">  627</span><span class="comment"> *        `target_payload_blob_func()` earlier.  The semantics of the first value is identical to that</span></div>
<div class="line"><a id="l00628" name="l00628"></a><span class="lineno">  628</span><span class="comment"> *        for `boost::asio::async_read()`.</span></div>
<div class="line"><a id="l00629" name="l00629"></a><span class="lineno">  629</span><span class="comment"> * @param target_payload_blob_func</span></div>
<div class="line"><a id="l00630" name="l00630"></a><span class="lineno">  630</span><span class="comment"> *        Function to execute at most once, when it is</span></div>
<div class="line"><a id="l00631" name="l00631"></a><span class="lineno">  631</span><span class="comment"> *        first indicated by the system that data might be available on the connection.  It is executed as if via</span></div>
<div class="line"><a id="l00632" name="l00632"></a><span class="lineno">  632</span><span class="comment"> *        `post(peer_socket-&gt;get_executor())`, but any executor bound to it (via `bind_executor()` is ignored).</span></div>
<div class="line"><a id="l00633" name="l00633"></a><span class="lineno">  633</span><span class="comment"> *        It takes no args and shall return `util::Blob_mutable` object</span></div>
<div class="line"><a id="l00634" name="l00634"></a><span class="lineno">  634</span><span class="comment"> *        describing the memory area into which we shall write on successful receipt of data.</span></div>
<div class="line"><a id="l00635" name="l00635"></a><span class="lineno">  635</span><span class="comment"> *        It will not be invoked at all, among other reasons, if `should_interrupt_func()` returns `true` the</span></div>
<div class="line"><a id="l00636" name="l00636"></a><span class="lineno">  636</span><span class="comment"> *        first time *it* is invoked.</span></div>
<div class="line"><a id="l00637" name="l00637"></a><span class="lineno">  637</span><span class="comment"> * @param should_interrupt_func</span></div>
<div class="line"><a id="l00638" name="l00638"></a><span class="lineno">  638</span><span class="comment"> *        Function to execute ahead of nb-reading arriving data (copying it from kernel buffer to</span></div>
<div class="line"><a id="l00639" name="l00639"></a><span class="lineno">  639</span><span class="comment"> *        the target buffer); hence the general loop is await-readable/call-this-function/nb-read/repeat</span></div>
<div class="line"><a id="l00640" name="l00640"></a><span class="lineno">  640</span><span class="comment"> *        (until the buffer is filled, there is an error, or `should_interrupt_func()` returns `true`).</span></div>
<div class="line"><a id="l00641" name="l00641"></a><span class="lineno">  641</span><span class="comment"> *        It is executed as if via `post(peer_socket-&gt;get_executor())`, but any executor bound to it (via</span></div>
<div class="line"><a id="l00642" name="l00642"></a><span class="lineno">  642</span><span class="comment"> *        `bind_executor()` is ignored).  It takes no args and shall return</span></div>
<div class="line"><a id="l00643" name="l00643"></a><span class="lineno">  643</span><span class="comment"> *        `bool` specifying whether to proceed with the operation (`false`) or to interrupt the whole thing (`true`).</span></div>
<div class="line"><a id="l00644" name="l00644"></a><span class="lineno">  644</span><span class="comment"> *        If it returns `true` then async_read_with_target_func() will *not* call `on_rcvd_or_error()`.</span></div>
<div class="line"><a id="l00645" name="l00645"></a><span class="lineno">  645</span><span class="comment"> *        Instead the user should consider `should_interrupt_func()` itself as the completion handler being invoked.</span></div>
<div class="line"><a id="l00646" name="l00646"></a><span class="lineno">  646</span><span class="comment"> */</span></div>
<div class="line"><a id="l00647" name="l00647"></a><span class="lineno">  647</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Task_err_blob, <span class="keyword">typename</span> Target_payload_blob_func, <span class="keyword">typename</span> Should_<span class="keywordtype">int</span>errupt_func&gt;</div>
<div class="line"><a id="l00648" name="l00648"></a><span class="lineno">  648</span><span class="keywordtype">void</span> <a class="code hl_function" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#acf7bdf0c727cbf0c5297125c762e1001">async_read_with_target_func</a></div>
<div class="line"><a id="l00649" name="l00649"></a><span class="lineno">  649</span>       (flow::log::Logger* logger_ptr,</div>
<div class="line"><a id="l00650" name="l00650"></a><span class="lineno">  650</span>        <a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">Peer_socket</a>* peer_socket,</div>
<div class="line"><a id="l00651" name="l00651"></a><span class="lineno">  651</span>        Target_payload_blob_func&amp;&amp; target_payload_blob_func,</div>
<div class="line"><a id="l00652" name="l00652"></a><span class="lineno">  652</span>        Should_interrupt_func&amp;&amp; should_interrupt_func,</div>
<div class="line"><a id="l00653" name="l00653"></a><span class="lineno">  653</span>        Task_err_blob&amp;&amp; on_rcvd_or_error);</div>
<div class="line"><a id="l00654" name="l00654"></a><span class="lineno">  654</span><span class="comment"></span> </div>
<div class="line"><a id="l00655" name="l00655"></a><span class="lineno">  655</span><span class="comment">/**</span></div>
<div class="line"><a id="l00656" name="l00656"></a><span class="lineno">  656</span><span class="comment"> * boost.asio extension similar to</span></div>
<div class="line"><a id="l00657" name="l00657"></a><span class="lineno">  657</span><span class="comment"> * `boost::asio::async_read(Peer_socket&amp;, Blob_mutable, Task_err_sz)` with the difference that it can be</span></div>
<div class="line"><a id="l00658" name="l00658"></a><span class="lineno">  658</span><span class="comment"> * canceled/interrupted via `should_interrupt_func()` in the same way as the otherwise more</span></div>
<div class="line"><a id="l00659" name="l00659"></a><span class="lineno">  659</span><span class="comment"> * complex async_read_with_target_func().</span></div>
<div class="line"><a id="l00660" name="l00660"></a><span class="lineno">  660</span><span class="comment"> *</span></div>
<div class="line"><a id="l00661" name="l00661"></a><span class="lineno">  661</span><span class="comment"> * So think of it as either:</span></div>
<div class="line"><a id="l00662" name="l00662"></a><span class="lineno">  662</span><span class="comment"> *   - `async_read()` with added `should_interrupt_func()` feature; or</span></div>
<div class="line"><a id="l00663" name="l00663"></a><span class="lineno">  663</span><span class="comment"> *   - `async_read_with_target_func()` minus `target_payload_blob_func()` feature.  Or formally, it&#39;s as-if</span></div>
<div class="line"><a id="l00664" name="l00664"></a><span class="lineno">  664</span><span class="comment"> *     that one was used but with a `target_payload_blob_func()` that simply returns `target_payload_blob`.</span></div>
<div class="line"><a id="l00665" name="l00665"></a><span class="lineno">  665</span><span class="comment"> *</span></div>
<div class="line"><a id="l00666" name="l00666"></a><span class="lineno">  666</span><span class="comment"> * Omitting detailed comments already present in async_read_with_target_func() doc header; just skip the</span></div>
<div class="line"><a id="l00667" name="l00667"></a><span class="lineno">  667</span><span class="comment"> * parts to do with `target_payload_blob_func()`.</span></div>
<div class="line"><a id="l00668" name="l00668"></a><span class="lineno">  668</span><span class="comment"> *</span></div>
<div class="line"><a id="l00669" name="l00669"></a><span class="lineno">  669</span><span class="comment"> * @tparam Task_err</span></div>
<div class="line"><a id="l00670" name="l00670"></a><span class="lineno">  670</span><span class="comment"> *         See `on_rcvd_or_error` arg.</span></div>
<div class="line"><a id="l00671" name="l00671"></a><span class="lineno">  671</span><span class="comment"> * @tparam Should_interrupt_func</span></div>
<div class="line"><a id="l00672" name="l00672"></a><span class="lineno">  672</span><span class="comment"> *         See async_read_with_target_func().</span></div>
<div class="line"><a id="l00673" name="l00673"></a><span class="lineno">  673</span><span class="comment"> * @param logger_ptr</span></div>
<div class="line"><a id="l00674" name="l00674"></a><span class="lineno">  674</span><span class="comment"> *        See async_read_with_target_func().</span></div>
<div class="line"><a id="l00675" name="l00675"></a><span class="lineno">  675</span><span class="comment"> * @param peer_socket</span></div>
<div class="line"><a id="l00676" name="l00676"></a><span class="lineno">  676</span><span class="comment"> *        See async_read_with_target_func().</span></div>
<div class="line"><a id="l00677" name="l00677"></a><span class="lineno">  677</span><span class="comment"> * @param on_rcvd_or_error</span></div>
<div class="line"><a id="l00678" name="l00678"></a><span class="lineno">  678</span><span class="comment"> *        The completion handler; it is passed either the success code (all requested bytes were read),</span></div>
<div class="line"><a id="l00679" name="l00679"></a><span class="lineno">  679</span><span class="comment"> *        or an error code (pipe is hosed).</span></div>
<div class="line"><a id="l00680" name="l00680"></a><span class="lineno">  680</span><span class="comment"> * @param target_payload_blob</span></div>
<div class="line"><a id="l00681" name="l00681"></a><span class="lineno">  681</span><span class="comment"> *        `util::Blob_mutable` object</span></div>
<div class="line"><a id="l00682" name="l00682"></a><span class="lineno">  682</span><span class="comment"> *        describing the memory area into which we shall write on successful receipt of data.</span></div>
<div class="line"><a id="l00683" name="l00683"></a><span class="lineno">  683</span><span class="comment"> * @param should_interrupt_func</span></div>
<div class="line"><a id="l00684" name="l00684"></a><span class="lineno">  684</span><span class="comment"> *        See async_read_with_target_func().</span></div>
<div class="line"><a id="l00685" name="l00685"></a><span class="lineno">  685</span><span class="comment"> */</span></div>
<div class="line"><a id="l00686" name="l00686"></a><span class="lineno">  686</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Task_err, <span class="keyword">typename</span> Should_<span class="keywordtype">int</span>errupt_func&gt;</div>
<div class="line"><a id="l00687" name="l00687"></a><span class="lineno">  687</span><span class="keywordtype">void</span> <a class="code hl_function" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#ae811e863245b8226af4c40d373ed9a73">async_read_interruptible</a></div>
<div class="line"><a id="l00688" name="l00688"></a><span class="lineno">  688</span>       (flow::log::Logger* logger_ptr, <a class="code hl_typedef" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">Peer_socket</a>* peer_socket, <a class="code hl_typedef" href="namespaceipc_1_1util.html#a6cb62ae434900f3a8915b33ec5d61a96">util::Blob_mutable</a> target_payload_blob,</div>
<div class="line"><a id="l00689" name="l00689"></a><span class="lineno">  689</span>        Should_interrupt_func&amp;&amp; should_interrupt_func, Task_err&amp;&amp; on_rcvd_or_error);</div>
<div class="line"><a id="l00690" name="l00690"></a><span class="lineno">  690</span><span class="comment"></span> </div>
<div class="line"><a id="l00691" name="l00691"></a><span class="lineno">  691</span><span class="comment">/**</span></div>
<div class="line"><a id="l00692" name="l00692"></a><span class="lineno">  692</span><span class="comment"> * Little utility that returns the raw Native_handle suitable for #Peer_socket to the OS.</span></div>
<div class="line"><a id="l00693" name="l00693"></a><span class="lineno">  693</span><span class="comment"> * This is helpful to close, without invoking a native API (`close()` really), a value returned by</span></div>
<div class="line"><a id="l00694" name="l00694"></a><span class="lineno">  694</span><span class="comment"> * `Peer_socket::release()` or, perhaps, received over a `Native_socket_stream`.</span></div>
<div class="line"><a id="l00695" name="l00695"></a><span class="lineno">  695</span><span class="comment"> *</span></div>
<div class="line"><a id="l00696" name="l00696"></a><span class="lineno">  696</span><span class="comment"> * The in-arg is nullified (it becomes `.null()`).</span></div>
<div class="line"><a id="l00697" name="l00697"></a><span class="lineno">  697</span><span class="comment"> *</span></div>
<div class="line"><a id="l00698" name="l00698"></a><span class="lineno">  698</span><span class="comment"> * Nothing is logged; no errors are emitted.  This is intended for no-questions-asked cleanup.</span></div>
<div class="line"><a id="l00699" name="l00699"></a><span class="lineno">  699</span><span class="comment"> *</span></div>
<div class="line"><a id="l00700" name="l00700"></a><span class="lineno">  700</span><span class="comment"> * @param peer_socket_native_or_null</span></div>
<div class="line"><a id="l00701" name="l00701"></a><span class="lineno">  701</span><span class="comment"> *        The native socket to close.  No-op (not an error) if it is `.null()`.</span></div>
<div class="line"><a id="l00702" name="l00702"></a><span class="lineno">  702</span><span class="comment"> *        If not `.null()`, `peer_socket_native_or_null.m_native_handle` must be suitable for</span></div>
<div class="line"><a id="l00703" name="l00703"></a><span class="lineno">  703</span><span class="comment"> *        `Peer_socket::native_handle()`.  In practice the use case informing release_native_peer_socket()</span></div>
<div class="line"><a id="l00704" name="l00704"></a><span class="lineno">  704</span><span class="comment"> *        is: `peer_socket_native = p.release()`, where `p` is a `Peer_socket`.  Update:</span></div>
<div class="line"><a id="l00705" name="l00705"></a><span class="lineno">  705</span><span class="comment"> *        Another use case came about: receiving `peer_socket_native` over a `Native_socket_stream`.</span></div>
<div class="line"><a id="l00706" name="l00706"></a><span class="lineno">  706</span><span class="comment"> */</span></div>
<div class="line"><a id="l00707" name="l00707"></a><span class="lineno">  707</span><span class="keywordtype">void</span> <a class="code hl_function" href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#af0833f160dffd7f1c6921d27883a186b">release_native_peer_socket</a>(<a class="code hl_struct" href="structipc_1_1util_1_1Native__handle.html">Native_handle</a>&amp;&amp; peer_socket_native_or_null);</div>
<div class="line"><a id="l00708" name="l00708"></a><span class="lineno">  708</span> </div>
<div class="line"><a id="l00709" name="l00709"></a><span class="lineno">  709</span>} <span class="comment">// namespace ipc::transport::asio_local_stream_socket</span></div>
<div class="ttc" id="aclassipc_1_1transport_1_1asio__local__stream__socket_1_1Opt__peer__process__credentials_html"><div class="ttname"><a href="classipc_1_1transport_1_1asio__local__stream__socket_1_1Opt__peer__process__credentials.html">ipc::transport::asio_local_stream_socket::Opt_peer_process_credentials</a></div><div class="ttdoc">Gettable (read-only) socket option for use with asio_local_stream_socket::Peer_socket ....</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8hpp_source.html#l00052">asio_local_stream_socket.hpp:54</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html">ipc::transport::asio_local_stream_socket</a></div><div class="ttdoc">Additional (versus boost.asio) APIs for advanced work with local stream (Unix domain) sockets includi...</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8cpp_source.html#l00031">asio_local_stream_socket.cpp:32</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_a05656e297b98f4c370841d2f9be52a5f"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a05656e297b98f4c370841d2f9be52a5f">ipc::transport::asio_local_stream_socket::Endpoint</a></div><div class="ttdeci">Protocol::endpoint Endpoint</div><div class="ttdoc">Short-hand for boost.asio Unix domain peer stream-socket endpoint.</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket__fwd_8hpp_source.html#l00117">asio_local_stream_socket_fwd.hpp:117</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_a0ad6afc0bbf995a5b84528f96315f4a2"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a0ad6afc0bbf995a5b84528f96315f4a2">ipc::transport::asio_local_stream_socket::Protocol</a></div><div class="ttdeci">local_ns::stream_protocol Protocol</div><div class="ttdoc">Short-hand for boost.asio Unix domain stream-socket protocol.</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket__fwd_8hpp_source.html#l00108">asio_local_stream_socket_fwd.hpp:108</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_a1022dfd42e9a0d6eab8384b0352decb0"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1022dfd42e9a0d6eab8384b0352decb0">ipc::transport::asio_local_stream_socket::nb_write_some_with_native_handle</a></div><div class="ttdeci">size_t nb_write_some_with_native_handle(flow::log::Logger *logger_ptr, Peer_socket *peer_socket_ptr, Native_handle payload_hndl, const util::Blob_const &amp;payload_blob, Error_code *err_code)</div><div class="ttdoc">boost.asio extension similar to peer_socket-&gt;non_blocking(true); auto n = peer_socket-&gt;write_some(pay...</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8cpp_source.html#l00036">asio_local_stream_socket.cpp:36</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_a154986f10d30d850de86fc3924766e66"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a154986f10d30d850de86fc3924766e66">ipc::transport::asio_local_stream_socket::Acceptor</a></div><div class="ttdeci">Protocol::acceptor Acceptor</div><div class="ttdoc">Short-hand for boost.asio Unix domain stream-socket acceptor (listening guy) socket.</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket__fwd_8hpp_source.html#l00111">asio_local_stream_socket_fwd.hpp:111</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_a1788f9dbd896bb71b3693f9ae25b40ae"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a1788f9dbd896bb71b3693f9ae25b40ae">ipc::transport::asio_local_stream_socket::Peer_socket</a></div><div class="ttdeci">Protocol::socket Peer_socket</div><div class="ttdoc">Short-hand for boost.asio Unix domain peer stream-socket (usually-connected-or-empty guy).</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket__fwd_8hpp_source.html#l00114">asio_local_stream_socket_fwd.hpp:114</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_a68071e53f4a048084f8ad26ff3ac6711"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a68071e53f4a048084f8ad26ff3ac6711">ipc::transport::asio_local_stream_socket::async_write_with_native_handle</a></div><div class="ttdeci">void async_write_with_native_handle(flow::log::Logger *logger_ptr, Peer_socket *peer_socket_ptr, Native_handle payload_hndl, const util::Blob_const &amp;payload_blob, Task_err &amp;&amp;on_sent_or_error)</div><div class="ttdoc">boost.asio extension similar to boost::asio::async_write(Peer_socket&amp;, Blob_const,...</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8hpp_source.html#l00171">asio_local_stream_socket.hpp:171</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_a9ae82b2a234b218704c62fb616d6fcc5"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#a9ae82b2a234b218704c62fb616d6fcc5">ipc::transport::asio_local_stream_socket::nb_read_some_with_native_handle</a></div><div class="ttdeci">size_t nb_read_some_with_native_handle(flow::log::Logger *logger_ptr, Peer_socket *peer_socket_ptr, Native_handle *target_payload_hndl_ptr, const util::Blob_mutable &amp;target_payload_blob, Error_code *err_code, int message_flags)</div><div class="ttdoc">boost.asio extension similar to peer_socket-&gt;non_blocking(true); auto n = peer_socket-&gt;read_some(targ...</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8cpp_source.html#l00201">asio_local_stream_socket.cpp:201</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_acf7bdf0c727cbf0c5297125c762e1001"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#acf7bdf0c727cbf0c5297125c762e1001">ipc::transport::asio_local_stream_socket::async_read_with_target_func</a></div><div class="ttdeci">void async_read_with_target_func(flow::log::Logger *logger_ptr, Peer_socket *peer_socket, Target_payload_blob_func &amp;&amp;target_payload_blob_func, Should_interrupt_func &amp;&amp;should_interrupt_func, Task_err_blob &amp;&amp;on_rcvd_or_error)</div><div class="ttdoc">boost.asio extension similar to boost::asio::async_read(Peer_socket&amp;, Blob_mutable,...</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8hpp_source.html#l00234">asio_local_stream_socket.hpp:235</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_ae811e863245b8226af4c40d373ed9a73"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#ae811e863245b8226af4c40d373ed9a73">ipc::transport::asio_local_stream_socket::async_read_interruptible</a></div><div class="ttdeci">void async_read_interruptible(flow::log::Logger *logger_ptr, Peer_socket *peer_socket, util::Blob_mutable target_payload_blob, Should_interrupt_func &amp;&amp;should_interrupt_func, Task_err &amp;&amp;on_rcvd_or_error)</div><div class="ttdoc">boost.asio extension similar to boost::asio::async_read(Peer_socket&amp;, Blob_mutable,...</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8hpp_source.html#l00268">asio_local_stream_socket.hpp:269</a></div></div>
<div class="ttc" id="anamespaceipc_1_1transport_1_1asio__local__stream__socket_html_af0833f160dffd7f1c6921d27883a186b"><div class="ttname"><a href="namespaceipc_1_1transport_1_1asio__local__stream__socket.html#af0833f160dffd7f1c6921d27883a186b">ipc::transport::asio_local_stream_socket::release_native_peer_socket</a></div><div class="ttdeci">void release_native_peer_socket(Native_handle &amp;&amp;peer_socket_native_or_null)</div><div class="ttdoc">Little utility that returns the raw Native_handle suitable for Peer_socket to the OS.</div><div class="ttdef"><b>Definition:</b> <a href="asio__local__stream__socket_8cpp_source.html#l00415">asio_local_stream_socket.cpp:415</a></div></div>
<div class="ttc" id="anamespaceipc_1_1util_html_a6cb62ae434900f3a8915b33ec5d61a96"><div class="ttname"><a href="namespaceipc_1_1util.html#a6cb62ae434900f3a8915b33ec5d61a96">ipc::util::Blob_mutable</a></div><div class="ttdeci">boost::asio::mutable_buffer Blob_mutable</div><div class="ttdoc">Short-hand for an mutable blob somewhere in memory, stored as exactly a void* and a size_t.</div><div class="ttdef"><b>Definition:</b> <a href="util__fwd_8hpp_source.html#l00140">util_fwd.hpp:140</a></div></div>
<div class="ttc" id="anamespaceipc_1_1util_html_ae0be7edba7e30ffa3f8b742af621f2ab"><div class="ttname"><a href="namespaceipc_1_1util.html#ae0be7edba7e30ffa3f8b742af621f2ab">ipc::util::Blob_const</a></div><div class="ttdeci">boost::asio::const_buffer Blob_const</div><div class="ttdoc">Short-hand for an immutable blob somewhere in memory, stored as exactly a void const * and a size_t.</div><div class="ttdef"><b>Definition:</b> <a href="util__fwd_8hpp_source.html#l00134">util_fwd.hpp:134</a></div></div>
<div class="ttc" id="anamespaceipc_html_aa3192e586cc45d3e7c22463bf2760f89"><div class="ttname"><a href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">ipc::Error_code</a></div><div class="ttdeci">flow::Error_code Error_code</div><div class="ttdoc">Short-hand for flow::Error_code which is very common.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00298">common.hpp:298</a></div></div>
<div class="ttc" id="anative__handle_8hpp_html"><div class="ttname"><a href="native__handle_8hpp.html">native_handle.hpp</a></div></div>
<div class="ttc" id="astructipc_1_1util_1_1Native__handle_html"><div class="ttname"><a href="structipc_1_1util_1_1Native__handle.html">ipc::util::Native_handle</a></div><div class="ttdoc">A monolayer-thin wrapper around a native handle, a/k/a descriptor a/k/a FD.</div><div class="ttdef"><b>Definition:</b> <a href="native__handle_8hpp_source.html#l00062">native_handle.hpp:63</a></div></div>
<div class="ttc" id="atransport__fwd_8hpp_html"><div class="ttname"><a href="transport__fwd_8hpp.html">transport_fwd.hpp</a></div></div>
<div class="ttc" id="autil__fwd_8hpp_html"><div class="ttname"><a href="util__fwd_8hpp.html">util_fwd.hpp</a></div></div>
</div><!-- fragment --></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Fri Apr 11 2025 20:02:25 for Flow-IPC by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
